Re: bash tab variable expansion question?

[Sebastian Siebert]

Am 02.09.2011 21:32, schrieb Chet Ramey:

On 2/24/11 5:14 PM, Michael Kalisz wrote:


Bash Version: 4.2
Patch Level: 0
Release Status: release

Description:

Hi!

Example:

In bash, version 4.1.5(1)-release:

$ echo $PWD/
will expand the $PWD variable to your current directory

while in bash, version 4.2.0(1)-release:

$ echo $PWD/
will just escape the $ in front of the $ variable i.e:

$ echo \$PWD/
The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB

Any hints why? Any way to get the 4.1 behavior in 4.2?


I wrote, in a subsequent message in a related thread:


The difference is that bash-4.1 expanded $HOME and left the expansion
as part of the replacement text.  Bash-4.2 tries to leave what the
user typed alone, but that leads to an inherently ambiguous situation:
when do you quote the `$' in a filename (or, in this case, a directory
name)?  It could be a shell variable, and it could be a character in
the filename.


That is the problem, in a nutshell.  I posted a partial patch at the
end of March that applied a heuristic to avoid quoting variable
expansions in most cases, but there was no way to get the bash-4.1
behavior back.

The attached patch adds a new shell option that, when enabled, is
intended to restore the bash-4.1 behavior of expanding directory names
in filenames being completed.  I have done some testing, and it seems
to work the way I intend.  This, or some later version, will be part
of the next bash release.  I am soliciting feedback on this iteration.

I'm sending this directly to everyone who's commented negatively about
the default bash-4.2 behavior, as well as bug-bash.  Please try the new
option (`direxpand') and let me know if it's missing anything.  The patch
includes the original heuristic I sent out back in March, the new shopt
option, and updates to the documentation and test suite.  It should apply
cleanly to bash-4.2.10.

Chet


Hi Chet,

Thanks for the great patch.

I have applied your patch in our bash 4.2 + Patchlevel 20. It is solved 
an issue with variable expansion. But on the other side bash completion 
is broken. :-(


Bash completion with local file (./some_script.sh, e.g.) would not be 
working:


# ./some_sc 

Current result:
# ./some_sc

Expected result:
# ./some_script.sh

It seems that the bash completion stops working.

I have added another patch to fix this issue. It would be nice if you 
have a look to the patch and let me know if this is ok.


Thank you.


--
Kind regards, Sebastian - openSUSE Member (Freespacer)
Website/Blog: 
Important notes on openSUSE Mailing List:

diff -rup bash-4.2.orig/bashline.c bash-4.2/bashline.c
--- bash-4.2.orig/bashline.c	2012-02-29 10:28:32.196236258 +0100
+++ bash-4.2/bashline.c	2012-02-29 12:57:15.071591691 +0100
@@ -2722,7 +2722,7 @@ set_directory_hook ()
   if (dircomplete_expand)
 {
   rl_directory_completion_hook = bash_directory_completion_hook;
-  rl_directory_rewrite_hook = (rl_icppfunc_t *)0;
+  rl_directory_rewrite_hook = bash_directory_completion_hook;
 }
   else
 {

Re: bash tab variable expansion question?

[Chet Ramey]

On 3/5/12 2:07 PM, Sebastian Siebert wrote:

> Thanks for the great patch.
> 
> I have applied your patch in our bash 4.2 + Patchlevel 20. It is solved an
> issue with variable expansion. But on the other side bash completion is
> broken. :-(
> 
> Bash completion with local file (./some_script.sh, e.g.) would not be working:
> 
> # ./some_sc 
> 
> Current result:
> # ./some_sc
> 
> Expected result:
> # ./some_script.sh
> 
> It seems that the bash completion stops working.
> 
> I have added another patch to fix this issue. It would be nice if you have
> a look to the patch and let me know if this is ok.

Thanks.  This is not the correct fix for that particular problem.  Please
look at the `direxpand' branch of the bash git tree at

http://git.savannah.gnu.org/cgit/bash.git/?h=direxpand

for a version of bash-4.2.20 with an updated direxpand patch applied.
This problem is fixed there.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bash tab variable expansion question?

[Sebastian Siebert]

On 05.03.2012 21:28, Chet Ramey wrote:

On 3/5/12 2:07 PM, Sebastian Siebert wrote:


Thanks for the great patch.

I have applied your patch in our bash 4.2 + Patchlevel 20. It is solved an
issue with variable expansion. But on the other side bash completion is
broken. :-(

Bash completion with local file (./some_script.sh, e.g.) would not be working:

# ./some_sc

Current result:
# ./some_sc

Expected result:
# ./some_script.sh

It seems that the bash completion stops working.

I have added another patch to fix this issue. It would be nice if you have
a look to the patch and let me know if this is ok.


Thanks.  This is not the correct fix for that particular problem.  Please
look at the `direxpand' branch of the bash git tree at

http://git.savannah.gnu.org/cgit/bash.git/?h=direxpand

for a version of bash-4.2.20 with an updated direxpand patch applied.
This problem is fixed there.

Chet



Hi Chet,

thank you to point me out to the correct patch. :-) I will used this 
patch for the bash 4.2 + PL 20.


--
Kind regards, Sebastian - openSUSE Member (Freespacer)
Website/Blog: 
Important notes on openSUSE Mailing List:

DJGPP build

[fabrizio gennari]

Hello.

I tried to build bash-4.2 for the DJGPP (GNU for MS-DOS) 
platform. It had been done before, but the latest available version was 
2.04.

Something interesting has been found in the process. First: 
version.c protects the use of snprintf with #if defined 
(HAVE_SNPRINTF). But HAVE_SNPRINTF is always defined, only it is 
defined as 0 if snprintf is not available. Here is a patch to fix that.


diff -ru bash-4.2/version.c bash-4.2-new/version.c
--- bash-4.2
/version.c  2011-01-28 17:32:36.0 +0100
+++ bash-4.2-new/version.
c   2012-03-05 08:05:18.778875000 +0100
@@ -64,13 +64,13 @@
   if (tt[0] 
== '\0')
 {
   if (release_status)
-#if defined (HAVE_SNPRINTF)

+#if  (HAVE_SNPRINTF)
snprintf (tt, sizeof (tt), "%s.%d(%d)-%s", 
dist_version, patch_level, build_version, release_status);
 #else

sprintf (tt, "%s.%d(%d)-%s", dist_version, patch_level, build_version, 
release_status);
 #endif
   else
-#if defined (HAVE_SNPRINTF)
+#if  
(HAVE_SNPRINTF)
snprintf (tt, sizeof (tt), "%s.%d(%d)", dist_version, 
patch_level, build_version);
 #else
sprintf (tt, "%s.%d(%d)", 
dist_version, patch_level, build_version);

Second, the variable 
job_control is only declared when JOB_CONTROL is #define'd. Yet, there 
is one case where its use is not protected by a suitable #if. Here's a 
patch to fix that.

diff -ru bash-4.2/execute_cmd.c bash-4.2-
new/execute_cmd.c
--- bash-4.2/execute_cmd.c  2011-02-09 23:32:
25.0 +0100
+++ bash-4.2-new/execute_cmd.c  2012-03-05 08:08:
31.98200 +0100
@@ -2202,7 +2202,11 @@
   /* If the `lastpipe' 
option is set with shopt, and job control is not
  enabled, execute 
the last element of non-async pipelines in the
  current shell 
environment. */
-  if (lastpipe_opt && job_control == 0 && asynchronous 
== 0 && pipe_out == NO_PIPE && prev > 0)
+  if (lastpipe_opt
+#if 
defined (JOB_CONTROL)
+  && job_control == 0
+#endif /*defined 
(JOB_CONTROL)*/
+  && asynchronous == 0 && pipe_out == NO_PIPE && prev 
> 0)
 {
   lstdin = move_to_high_fd (0, 0, 255);
   if 
(lstdin > 0)

Third, a comment in posixdir.h says "Posix does not 
require that the d_ino field be present, and some systems do not 
provide it". But the #if statement immediately above seems to implay 
that all non-Posix systems have it, because it assumes that it is 
always present if _POSIX_SOURCE is not defined. The following patch 
conditions the use of d_ino to the fact that configure successfully 
tests it, independently of _POSIX_SOURCE. Also, it avoids using 
d_fileno not only when d_ino is broken, but also when it is missing 
altogether.

diff -ru bash-4.2/include/posixdir.h bash-4.2-
new/include/posixdir.h
--- bash-4.2/include/posixdir.h 2008-08-12 16:01:
57.0 +0200
+++ bash-4.2-new/include/posixdir.h 2012-03-05 19:28:
05.73200 +0100
@@ -50,7 +50,7 @@
 #  define d_fileno d_ino
 #endif

 
-#if defined (_POSIX_SOURCE) && (!defined (HAVE_STRUCT_DIRENT_D_INO) 
|| defined (BROKEN_DIRENT_D_INO))
+#if (!defined 
(HAVE_STRUCT_DIRENT_D_INO) || defined (BROKEN_DIRENT_D_INO))
 /* Posix 
does not require that the d_ino field be present, and some
systems 
do not provide it. */
 #  define REAL_DIR_ENTRY(dp) 1
diff -ru bash-4.2
/lib/sh/getcwd.c bash-4.2-new/lib/sh/getcwd.c
--- bash-4.2
/lib/sh/getcwd.c2009-06-17 02:16:55.0 +0200
+++ bash-4.2-
new/lib/sh/getcwd.c 2012-03-05 21:08:28.26325 +0100
@@ -48,7 +48,7 
@@
 
 #include 
 
-#if defined (BROKEN_DIRENT_D_INO)
+#if 
defined (BROKEN_DIRENT_D_INO) || (!defined (HAVE_STRUCT_DIRENT_D_INO) 
&& !defined (HAVE_STRUCT_DIRENT_D_FILENO))
 #  include "command.h"
 #  
include "general.h"
 #  include "externs.h"
@@ -71,7 +71,7 @@
 /* If 
the d_fileno member of a struct dirent doesn't return anything useful,

we need to check inode number equivalence the hard way.  Return 1 
if
the inode corresponding to PATH/DIR is identical to THISINO. */
-
#if defined (BROKEN_DIRENT_D_INO)
+#if defined (BROKEN_DIRENT_D_INO) || 
(!defined (HAVE_STRUCT_DIRENT_D_INO) && !defined 
(HAVE_STRUCT_DIRENT_D_FILENO))
 static int
 _path_checkino (dotp, name, 
thisino)
  char *dotp;
@@ -206,7 +206,7 @@
  (d->d_name[1] == 
'\0' ||
(d->d_name[1] == '.' && d->d_name[2] == '\0')))

continue;
-#if !defined (BROKEN_DIRENT_D_INO)
+#if !defined 
(BROKEN_DIRENT_D_INO) && (defined (HAVE_STRUCT_DIRENT_D_INO) || defined 
(HAVE_STRUCT_DIRENT_D_FILENO))
  if (mount_point || d->d_fileno == 
thisino)
 #else
  if (mount_point || _path_checkino (dotp, d->d_name, 
thisino))

If the above patches were applied, it would be a big step 
towards having a new version of bash for DJGPP. It wouldn't be enough, 
because DJGPP does not support the signals SIGCHLD and SIGWINCH and the 
flag SA_RESTART. And the code would improve anyway, because they fixed 
some little-tested cases.

Regards,
Fabrizio


E' nata indoona: chiama, videochiama e messaggia Gratis

doing operations with bash script

[alphabah]

Dear all,

I am trying to do some operation within a bash script but I am running into
problems very early.

Say I want to do the following:
-
omegaNew=`echo "$omegaNew+$torque*$dt/$momentOfInertia*180/$pi" | bc -l`
---
I got these outputs:
-
torque= -0.0665625 dt= 0.0012 omegaNew= -.00026392835805117909
torque= 0.48041 dt= 0.000101208 omegaNew= -.00010327107397767696
(standard_in) 1: syntax error
torque= 1.14457 dt= 2.39891e-05 omegaNew=
---
Does this mean that the operation is not carried if the torque is not in the
form 0.**?
If so, why is that?

Another unrelated question:
I got this output message,
--
sed: -e expression #1, char 1: unknown command: `C'
-
even the command did what it was supposed to do (i.e., inserting a line)
whould one know how to get rid of this thing?

Best regards to all.



-- 
View this message in context: 
http://old.nabble.com/doing-operations-with-bash-script-tp33447614p33447614.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: doing operations with bash script

[alphabah]

I found where the error is coming from.
it is rather form dt that is written in exponential format and not from
torque.
Now I have to convert it in decimal format.



alphabah wrote:
> 
> Dear all,
> 
> I am trying to do some operation within a bash script but I am running
> into problems very early.
> 
> Say I want to do the following:
> -
> omegaNew=`echo "$omegaNew+$torque*$dt/$momentOfInertia*180/$pi" | bc -l`
> ---
> I got these outputs:
> -
> torque= -0.0665625 dt= 0.0012 omegaNew= -.00026392835805117909
> torque= 0.48041 dt= 0.000101208 omegaNew= -.00010327107397767696
> (standard_in) 1: syntax error
> torque= 1.14457 dt= 2.39891e-05 omegaNew=
> ---
> Does this mean that the operation is not carried if the torque is not in
> the form 0.**?
> If so, why is that?
> 
> Another unrelated question:
> I got this output message,
> --
> sed: -e expression #1, char 1: unknown command: `C'
> -
> even the command did what it was supposed to do (i.e., inserting a line)
> whould one know how to get rid of this thing?
> 
> Best regards to all.
> 
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/doing-operations-with-bash-script-tp33447614p33448226.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.