Re: tab completing `/ cause weird errors messages.

[Davide Brini]

On Sun, 26 Jun 2022 02:27:59 +0200, Emanuele Torre
 wrote:


> Description:
> Tab completing `/ (backtick-slash) causes bash to print lots of
> weird error messages.

FWIW, this happens for any path, even not terminated by slash, at least on
my system:

$ cat `/usr/
-l: bad substitution: no closing "`" in `/usr/bin
-l: bad substitution: no closing "`" in `/usr/bin
bin  -l: bad substitution: no closing "`" in `/usr/include
-l: bad substitution: no closing "`" in `/usr/include
include  -l: bad substitution: no closing "`" in `/usr/lib
-l: bad substitution: no closing "`" in `/usr/lib
lib  -l: bad substitution: no closing "`" in `/usr/lib32
-l: bad substitution: no closing "`" in `/usr/lib32
lib32-l: bad substitution: no closing "`" in `/usr/lib64
-l: bad substitution: no closing "`" in `/usr/lib64
lib64-l: bad substitution: no closing "`" in `/usr/local
-l: bad substitution: no closing "`" in `/usr/local
local-l: bad substitution: no closing "`" in `/usr/sbin
-l: bad substitution: no closing "`" in `/usr/sbin
sbin -l: bad substitution: no closing "`" in `/usr/share
-l: bad substitution: no closing "`" in `/usr/share
share-l: bad substitution: no closing "`" in `/usr/src
-l: bad substitution: no closing "`" in `/usr/src
src


$ cat `/u-l: bad substitution: no closing "`" in `/usr
sr/

$ cat `/tm-l: bad substitution: no closing "`" in `/tmp
p/


$ bash --version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)


--
D.

Re: Change in indirect expansion behavior from 4.4 to 5.0

[Davide Brini]

On Tue, 29 Sep 2020 21:28:59 -0700, Jason Miller  wrote:

> Gentoo linux, GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu)
>
> On the above vesion of bash, the following script will not run the echo
> command and print an error.  On bash 4.4 it appears to  treat the ${!foo}
> the same as expanding an unset variable and thus outputs "bar":
>
>   unset foo
>   echo ${!foo} bar
>
> "shopt -s compat44" does not seem to make a difference

This is documented, and thus (I suppose) on purpose. See the file CHANGES:

This document details the changes between this version, bash-5.0-alpha, and
the previous version, bash-4.4-release.

...

y. If indirect expansion attempts to indirectly reference through an unset
   variable, report an error.

--
D.

Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

[Davide Brini]

On Sat, 29 Aug 2020 15:25:44 -0400, Bruce Lilly 
wrote:

> Unfortunately, because bash is GPL, I can't post the copyrighted script
> which is covered by a non-GPL license.

That's ridiculous. You don't have to post the whole script (neither should
you), just a simple code snippet that shows the issue.

--
D.

Re: Expand first before asking the question "Display all xxx possibilities?"

[Davide Brini]

On Thu, 6 Aug 2020 15:13:30 +0300, Ilkka Virta  wrote:

> I think they meant the case where all the files matching the given
> beginning have a longer prefix in common. The shell expands that prefix
> to the command line after asking to show all possibilities.
>
>   $ rm *
>   $ touch dan_home_bkp{1..199}
>   $ ls -l da[TAB]
>   Display all 199 possibilities? (y or n) [n]
>   $ ls -l dan_home_bkp[cursor here]
>
> So the shell has to fill in the common part anyway, and it might as well
> do it first, without asking.

Don't know about the OP's environment, but it works out of the box for me,
and it always has, as far as I can remember:

$ touch dan_home_bkp{1..199}
$ ls da[TAB]
$ ls dan_home_bkp[TAB][TAB]
Display all 199 possibilities? (y or n)

$ bash --version
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

--
D.

Re: bug in arithmetic expansion

[Davide Brini]

On Sat, 9 Nov 2019 11:52:56 +0100, Joern Knoll  wrote:

> [tplx99]:/the/knoll > echo $((0123))
> 83
> [tplx99]:/the/knoll > echo $((123))
> 123
> [tplx99]:/the/knoll > echo $((01234))
> 668
> [tplx99]:/the/knoll > echo $((1234))
> 1234

If you want to force base 10 interpretation (remember that leading 0 mean
octal in arithmetic context), you need to explicitly tell bash:

$ echo $(( 10#0123 ))
123

--
D.

Re: GNUbash v. 4.4.23-5 – Bash identifier location is non-correct in terminal

[Davide Brini]

On Mon, 29 Oct 2018 11:40:54 +0100, Ricky Tigg  wrote:

> Component: bash.x86_64 4.4.23-5.fc29 @fedora
> 
> To reproduce,: execute 'curl https://www.startpage.com'.
> 
> Actual result:
> 
> $ curl https://www.startpage.com
> (...)  [yk@localhost ~]$
> 
> Expected result:
> 
> $ curl https://www.startpage.com
> (...)
> [yk@localhost ~]$

That is most likely because the output of curl does not end with a newline.
Simpler reproducer:

$ printf '%s' hello
hello$

It's not a bash issue IMHO.

-- 
D.

Re: When reading less than wanted characters, "read" does not detect NUL bytes

[Davide Brini]

On Fri, 15 Jun 2018 15:15:23 +0200, Davide Brini  wrote:

> So it looks like the only "reliable" way to detect NULs in the input is to
> read one character at a time.

Your explanation got me thinking, and I've come up with the following code
that seems to be slightly more efficient than reading one byte at a time,
as it allows reading bigger chunks of data in the parts where there are no
delimiters (NULs). I'm posting it in case it helps someone. Works For Me
(TM).

--

to_read=512  # how many bytes to read at a time

while true; do

  IFS= read -d '' -r -n $to_read data

  status=$?
  length=${#data}

  # do whatever with what we got
  for ((i=0; i < length; i++)); do
printf "Read character %02x\n" "'${data:i:1}"
  done

  # if we read less than we wanted, and it's not EOF, it means we also have
  # a delimiter
  if [ $length -lt $to_read ] && [ $status -eq 0 ]; then
printf "Read a NUL\n"
  fi

  # exit if EOF
  if [ $status -ne 0 ]; then
break
  fi

done

--

Tests:

$ printf '\x00' | ./test.sh 
Read a NUL
$ printf '\x00\x00' | ./test.sh 
Read a NUL
Read a NUL
$ printf '\x00a\x00' | ./test.sh 
Read a NUL
Read character 61
Read a NUL
$ printf '' | ./test.sh 
$ printf 'abcd' | ./test.sh 
Read character 61
Read character 62
Read character 63
Read character 64
$ printf '\x001\x00\n' | ./test.sh 
Read a NUL
Read character 31
Read a NUL
Read character 0a

-- 
D.

Re: When reading less than wanted characters, "read" does not detect NUL bytes

[Davide Brini]

On Fri, 15 Jun 2018 09:07:46 -0400, Greg Wooledge 
wrote:

> On Fri, Jun 15, 2018 at 03:03:21PM +0200, Davide Brini wrote:
> > $ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 2 var; do echo
> > "read: $var, length: ${#var}"; done; } read: a, length: 1
> > read: , length: 0
> > read: bc, length: 2
> > 
> > I would expect there to be another read of length 0 between the "a" and
> > the "bc".  
> 
> Seems correct to me.  You asked it to stop reading when it finds a NUL
> or when it has read 2 characters.  The first time, they both happen at
> the same time, and you end up with "a", and two bytes have been consumed.
> 
> The second time, it happens after reading the NUL byte, so you get "" and
> a total of three bytes have been consumed.
> 
> The third time, you read "bc", and all the bytes have been consumed.

Oh I see, I was misled by the -n1 behavior and thought the delimiter somehow
would be "put back" for the next read, but your explanation makes sense.

So it looks like the only "reliable" way to detect NULs in the input is to
read one character at a time.

Thanks!

-- 
D.

When reading less than wanted characters, "read" does not detect NUL bytes

[Davide Brini]

Best explained with an example:

$ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 1 var; do echo "read: $var, 
length: ${#var}"; done; }
read: a, length: 1
read: , length: 0
read: , length: 0
read: b, length: 1
read: c, length: 1

This is as expected, and allows detecting a NUL in the input when the
length of $var is 0  (let's not talk about EOF and non-newline terminated
inputs here, this is not the issue).

However, if trying to read 2 (or more) characters at a time, it's no longer
true:

$ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 2 var; do echo "read: $var, 
length: ${#var}"; done; }
read: a, length: 1
read: , length: 0
read: bc, length: 2

I would expect there to be another read of length 0 between the "a" and the
"bc".

Apologies if this has been already discussed and/or if I'm missing
something.

$ bash --version
GNU bash, version 4.4.23(1)-release (x86_64-unknown-linux-gnu)

-- 
D.

Re: Backslashed space in variable/argument expansion does not prevent splitting.

[Davide Brini]

On Fri, 17 Jun 2016 11:21:42 +0100, Dean Wakerley  wrote:

> Description: The expansion of a variable containing spaces splits on all
> spaces including escaped/backslashed space.

It's not a bug, you probably want

eval ./echo_args.sh ${TCL_DEFS}

but you're sitting on very thin ice here.

-- 
D.

Re: bash hangs when using exec 2...

[Davide Brini]

On Sat, 14 Mar 2015 15:17:24 +0100, kont...@marcbihlmaier.de wrote:

 Description:
 exec hangs up when using exec 2SOMETHING. Just tested on
 Ubuntu 14.04, Ubuntu 12.04, Debian7
 working when just using exec 1SOMETHING
 
 Repeat-By:
 using in a script for logging
 or just try it in bash or dash 
 
 Fix:
 Dont't know how to fix it
 Just using the workaround with PATH/SCRIPT 2SOMETHING which
 does not use exec

It's not hanging, it's just that bash uses fd 2 to show the prompt and
what the user types. Try typing a command and hitting enter while bash seems
to be hung.

Alternatively, do a cat SOMETHING in another console, and you'll see the
prompts and the commands you typed.


-- 
D.

Re: Issues with exported functions

[Davide Brini]

On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey chet.ra...@case.edu wrote:

 On 9/24/14, 3:44 PM, lolilolicon wrote:
 
  Personally, I have never needed this feature. I would vote for its
  removal: It's very surprising, creates bugs, and is not very useful.
 
 There are more things in heaven and earth that are dreamt of in your
 philosophy.
 
  Otherwise, if this feature is going to stay (can anyone enlighten me why
  it's useful?), please document it explicitly.
 
 Function export is documented.  The exact mechanism need not be.

I'm not arguing about anything, I just have a question. I understand that
with the current method used to export functions, it is not possible to
export a variable to a child whose value begins exactly with the characters
in question. A quick test seems to confirm that:

$ x='() { echo a; }' bash -c 'echo $x'

$ x='()  { echo a; }' bash -c 'echo $x'
()  { echo a; }


So is there a way to be able to export variables with arbitrary values,
including '() {' ?  Sorry if this has been discussed before.

Thanks

-- 
D.

Re: Feature request - script directory

[Davide Brini]

On Tue, 16 Sep 2014 21:02:54 +0200, Łukasz Wieczorek
wieczorek1...@gmail.com wrote:

 I would like to propose a feature: a built-in/variable that returns/holds
 information about current script directory.
 This could help parsers to properly `source` files.
 Also please look how many people visited this page:
 http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what-directory-its-stored-in

See http://mywiki.wooledge.org/BashFAQ/028 (linked from that same page).

The script may not even exist anywhere, as bash may be reading commands
from standard input.

-- 
D.

Re: Substring Expansion does not work as intended

[Davide Brini]

On Wed, 20 Aug 2014 15:05:48 +0200, eckard.bra...@gmx.de wrote:

 Description:
   Substring Expansion actually works different than manpage states,
 namely:
 
   If offset evaluates to a number less than zero, the value is
 used as an offset from the end of the value of parameter.
 
 Repeat-By:
   x=abcdef; echo ${x:-2}
   Expected: ef
   Got:  abcdef
 
   or:
   x=abcdef; echo ${x:-2:1}
   Expected: e
   Got:  abcdef

One line below it also says: Note that a negative offset must be separated
from the colon by at least one space to avoid being confused  with  the  :-
expansion.

$ x=abcdef; echo ${x: -2}
ef
$ x=abcdef; echo ${x: -2:1}
e

-- 
D.

Re: Builtin 'read' data not saved

[Davide Brini]

On Thu, 2 Jan 2014 11:35:11 -0800, P Fudd f...@ch.pkts.ca wrote:

 Here's some more oddities:
 
 =failing.sh:
 #!/bin/bash
 R=1|2
 IFS='|' read -r A B  $R
 echo A=$A, B=$B
 
 Expected: A=1, B=2
 Actual: A=1 2, B=
 
 
 fail2.sh:
 #!/bin/bash
 R=1|2
 while IFS='|' read -r A B; do
 echo 1:A=$A, B=$B
 done  $R
 echo 2:A=$A, B=$B
 
 Expected:
   1:A=1, B=2
   2:A=1, B=2
 Actual:
   1:A=1, B=2
   2:A=, B=
 
 
 GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
 bash-4.2-2ubuntu2.1.deb

This is a FAQ, see http://mywiki.wooledge.org/BashFAQ/024 for a full
discussion.

-- 
D.

Re: Builtin 'read' data not saved

[Davide Brini]

On Thu, 2 Jan 2014 11:35:11 -0800, P Fudd f...@ch.pkts.ca wrote:

 Here's some more oddities:

Ok, the link I sent you is more about the issue you describe in your first
message. See below for more on the new ones in this message.

 =failing.sh:
 #!/bin/bash
 R=1|2
 IFS='|' read -r A B  $R
 echo A=$A, B=$B
 
 Expected: A=1, B=2
 Actual: A=1 2, B=

Here $R is expanded and wordsplitted using IFS before read is executed,
which means that $R does *not* contain any pipe symbol at the time read
is executed, so $A gets the whole thing.

 fail2.sh:
 #!/bin/bash
 R=1|2
 while IFS='|' read -r A B; do
 echo 1:A=$A, B=$B
 done  $R
 echo 2:A=$A, B=$B
 
 Expected:
   1:A=1, B=2
   2:A=1, B=2
 Actual:
   1:A=1, B=2
   2:A=, B=

This is slightly different, as when $R is expanded, IFS is still the
default, so it's expanded to 1|2 as expected, and the alternate IFS is
only in effect during the while/read loop. As expected, after the first
loop iteration $A is 1 and $B is 2. However read is executed once more, and
that second execution reads nothing, thus obviously setting both A and B
empty. Run with set -x and you'll see it yourself.

-- 
D.

Re: getting weird output out of 'echo' w/args

[Davide Brini]

On Thu, 30 May 2013 08:53:48 +0300, Pierre Gaston pierre.gas...@gmail.com
wrote:

 Missing quotes around [ ]  can be nasty eg
 
 #!/bin/bash
 shopt -s nullglob # sounds a good idea!
 .
 .
 i=0
 while read a[i++]; do
   echo ${a[i]} #  why oh why nothing is printed!
 done  hello

It seems to me this has nothing to do with missing quotes around [ ], or I
don't get what you mean.

-- 
D.

Re: getting weird output out of 'echo' w/args

[Davide Brini]

On Thu, 30 May 2013 16:56:36 +0800, Chris Down ch...@chrisdown.name wrote:

 Pierre is referring to the fact that [i++] is evaluated as a glob by
 the shell, the reason it doesn't work is because $i is postincremented
 instead of preincremented. You can see what he means here:
 
 $ shopt -u nullglob
 $ i=0
 $ while read a[++i]; do
  echo ${a[i]}
  done  hello
 hello
 $ shopt -s nullglob
 $ while read a[++i]; do
  echo ${a[i]}
  done  hello
 
 $

But he was doing postincrement, so it wouldn't have worked anyway, since
the code was assigning to a[0] and printing a[1].

PS: Better put a

a=()

before each run.

-- 
D.

Re: getting weird output out of 'echo' w/args

[Davide Brini]

On Thu, 30 May 2013 17:06:08 +0800, Chris Down ch...@chrisdown.name wrote:

 That's... why I said he was unintentionally doing postincrement...

Doh! Indeed you said that. Apologies for reading too fast.

-- 
D.

Re: Bash stating it is in a directory which does not exist

[Davide Brini]

On Tue, 19 Feb 2013 17:00:32 +1100, Nikolas Kallis n...@nikolaskallis.com
wrote:

 Hello,
 
 
 
 I have found a bug in Bash:
 
 /opt/foobar$
 /opt/foobar$ rmdir ../foobar/
 /opt/foobar$
 
 With the above, one can see I deleted the directory 'foobar/' from 
 within the directory itself. What one can also see is that after I 
 deleted the directory, I was still in it according to Bash.
 
 This is a bug because Bash is telling me something which is not true.
 
 To fix this, Bash needs poll to confirm the file system location its 
 working in still exists, and to to move to the next valid '../' when the 
 address it was working in no longer exists.
 
 Perhaps this can be done automaticly, automaticly only if there is no 
 input, or on the next return.
 On the next return would be safest I think.

Bash has nothing to do with this, it's an operating system level behavior.
If a process has a file open (ie, a file descriptor referring to that file)
and the file is deleted, the process can still use the file until it closes
it. However, the file ceases to be externally visible from the moment it's
removed, to stop other processes from using it.

When you're in /opt/foobar, bash has an open file descriptor referring to
the directory. If you (or anyone) deletes the directory, it's no longer
visible from the outside, but as long as there is at least a file
descriptor referring to it (which there is), the operating system keeps it
available to the processes using it. So really, to bash (and any process
that have it open, if there are others) the directory still exists.

/opt/foobar$ lsof | grep foobar
bash  10990 waldner  cwd   DIR 254,0 4096 17638570 
/opt/foobar
/opt/foobar$ rmdir ../foobar
/opt/foobar$ lsof | grep foobar
bash  10990 waldner  cwd   DIR 254,00 17638570 
/opt/foobar (deleted)
/opt/foobar$ cd ..
/opt/foobar$ lsof | grep foobar
/opt/foobar$

-- 
D.

Re: problem with extended regular expression in bash 4.1

[Davide Brini]

On Mon, 26 Nov 2012 15:03:35 +0100, Davide Brini dave...@gmx.com wrote:

 On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote:
 
   It changed between bash 3.1 and 3.2, documented in the NEWS file.
   There is
   
   a compat31 option that can be turned on to restore the 3.1 behavior.
   
  
  As you see it works for me in 3.25
 
 Then maybe you have the compat31 option set (or your distro sets it for
 you), or you may have a patched, non-vanilla version of bash (redhat is
 well known for doing this).
 

And indeed:

https://groups.google.com/forum/?fromgroups=#!topic/gnu.bash.bug/hq7mAJQB31s


-- 
D.

Re: problem with extended regular expression in bash 4.1

[Davide Brini]

On Mon, 26 Nov 2012 05:40:09 -0800 (PST), chupin...@gmail.com wrote:

  It changed between bash 3.1 and 3.2, documented in the NEWS file. There
  is
  
  a compat31 option that can be turned on to restore the 3.1 behavior.
  
 
 As you see it works for me in 3.25

Then maybe you have the compat31 option set (or your distro sets it for
you), or you may have a patched, non-vanilla version of bash (redhat is
well known for doing this).

-- 
D.

Re: problem with extended regular expression in bash 4.1

[Davide Brini]

On Sat, 24 Nov 2012 21:08:16 +, Alex Chupin (achupin)
achu...@cisco.com wrote:

 Dear All,
 
 Can someone shed light on the difference in behaviour of bash 4.1. and
 3.25? I am out of ideas. 
 
 Regards,
 Alexander Chupin
 
 $ bash --version; s=12345;if [[ $s =~ '^[0-9]+$' ]]; then echo it is a
 number; else echo it is NOT a number; fi GNU bash, version
 4.1.2(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2009 Free
 Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html This is free software; you are free to
 change and redistribute it. There is NO WARRANTY, to the extent permitted
 by law. it is NOT a number
 
 
 $ bash --version; s=12345;if [[ $s =~ '^[0-9]+$' ]]; then echo it is a
 number; else echo it is NOT a number; fi GNU bash, version
 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free
 Software Foundation, Inc. it is a number

It changed between bash 3.1 and 3.2, documented in the NEWS file. There is
a compat31 option that can be turned on to restore the 3.1 behavior.

See here: http://stackoverflow.com/questions/218156/bash-regex-with-quotes
In any case, keeping the pattern in a variable is safer and works with
all versions of bash.

-- 
D.

Re: Incorrect mangling of multiline array assignment in history

[Davide Brini]

On Thu, 07 Jun 2012 12:54:28 -0400, Chet Ramey chet.ra...@case.edu wrote:

 On 6/4/12 12:42 PM, Davide Brini wrote:
 
  Bash Version: 4.2
  Patch Level: 29
  Release Status: release
  
  Description:
  To insert them in the history, bash converts multiline commands
  into a single line, normally replacing newlines with semicolons.
  However, if the multiline command happens to be an array assignment,
  adding the semicolon isn't always correct.
  
  Repeat-By:
  
  I'm not sure exactly when it happens, however this seems to more or
  less trigger it regularly:
  
  $ xxx=(a b c d
  )
 
 It can, but it depends on the shell's state and the command before the
 assignment statement.

Yes, I noticed that sometimes it worked, but I couldn't understand exactly
why.

 The attached patch makes doing the right thing explicit rather than
 relying on shell state.  It seems to work for me; please try it and let
 me know.

I did a few tests and wasn't able to reproduce it, so I'd say it solves the
issue. Thanks!

-- 
D.

Incorrect mangling of multiline array assignment in history

[Davide Brini]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=x86-64 
-mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 
-D_FORTIFY_SOURCE=2 
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin'
 -DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin' 
-DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux beaker 3.3.7-1-ARCH #1 SMP PREEMPT Tue May 22 00:26:26 CEST 
2012 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

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

Description:
To insert them in the history, bash converts multiline commands into a 
single line, normally replacing newlines with semicolons. However, if the 
multiline command happens to be an array assignment, adding the semicolon isn't 
always correct.

Repeat-By:

I'm not sure exactly when it happens, however this seems to more or less 
trigger it regularly:

$ xxx=(a b c d
 )

(we hit enter after the d, to complete the assignment on the next line.  
is the PS2 prompt)

$ declare -p xxx
declare -a xxx='([0]=a [1]=b [2]=c [3]=d)'

Now hit up arrow twice to recall the array assignment and we get this:

$ xxx=(a b c d; )
-bash: syntax error near unexpected token `;'

Fix:
No idea!

Re: Bug, or someone wanna explain to me why this is a POSIX feature?

[Davide Brini]

On Mon, 08 Aug 2011 12:07:21 -0700, Linda Walsh b...@tlinx.org wrote:

 however, Can you explain the purpose of the shopt option 
 'no_empty_cmd_completion'
 and if you can do that, can you explain why I shouldn't use tab as an
 indent char on an empty line...?

Short answer: if you do

foo() {
  # hit tab here
 
(the  is the prompt bash gives you if you hit enter), that's NOT an
empty line as far as bash is concerned, so the option
no_empty_cmd_completion does not come into play. In fact, you could do the
same thing with

foo() { # hit tab here

and I'm sure you wouldn't consider that an empty line.

Note that it's not related specifically to declaring a function: try for
example

ls /tmp# hit enter here
  # hit tab here, you get the completions

And as already stated, POSIX has nothing to do with all this.

-- 
D.

Re: Bug, or someone wanna explain to me why this is a POSIX feature?

[Davide Brini]

On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini dave...@gmx.com wrote:

 In fact, you could do the same thing with
 
 foo() { # hit tab here
 
 and I'm sure you wouldn't consider that an empty line.

I have to take that back: it looks like bash treats the above differently
depending on whether enter was pressed or not:

foo() { # hit tab here
Display all 2138 possibilities? (y or n)

foo() {  # hit enter here
 # hit tab here
Display all 112 possibilities? (y or n)

The latter only attemps completion from names in the current directory.

On the other hand, with no_empty_cmd_completion set, no completion at all is
attempted in the first case, while the second case still attempts completion
from local names.

-- 
D.

Re: How to do? Possible?

[Davide Brini]

On Mon, 25 Jul 2011 14:28:52 -0700, Linda Walsh b...@tlinx.org wrote:

   Not really.
   It only seems that way because within () any $ is usually
 expanded BEFORE the () starts from the parent
 
   You can see this by
   GLOBAL=hi there
   (echo $GLOBAL)
 prints out hi there as expected, but if we hide
 $GLOBAL so it isn't seen by parent:
 (foo=GLOBAL; echo ${!foo})
 prints 
 
 So, they aren't really available in a subshell, only
 that a subshell's contents are evaluated before the subshell is
 called.

There is a distinction to make between exported and non-exported variables.
Also, 

foo=bar command

is quite different from

foo=bar; command

(although sometimes, under certain conditions, they may appear to yield the
same result).

-- 
D.

Re: When double quote is considered when not?

[Davide Brini]

On Wednesday 30 Mar 2011 11:13:58 ali hagigat wrote:

 The following scripts were run for /bin/bash, version 4.0.33, and then
 comes their outputs. In the second example seems to have a warning:
 binary operator expected. Why the error is generated? and why there
 is no error for the first example?
 --
 var1=word1 word2
 echo $var1
 if (test -z \$var1\)   then
 echo first
 else
 echo second
 fi
 
 word1 word2
 second
 --
 var1=word1 word2
 echo $var1
 if (test -z $var1)   then
 echo first
 else
 echo second
 fi
 
 word1 word2
 ./ss1: line 3: test: word1: binary operator expected
 second
 --

Use set -x at the beginning of the script and rerun it, and you'll 
immediately see why.

-- 
D.

Re: bash tab variable expansion question?

[Davide Brini]

On Friday 25 Feb 2011 05:15:24 Eric Blake wrote:

 On 02/24/2011 03:14 PM, Michael Kalisz wrote:
  $ echo $PWD/TAB
  will expand the $PWD variable to your current directory
  
  while in bash, version 4.2.0(1)-release:
  
  $ echo $PWD/TAB
  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?
  
  Can someone confirm... Is this a bug or a feature?
 
 I'm not the developer, but in my mind, this is a welcome feature.
 TAB-completion should NOT modify what I typed, and I consider the 4.1
 behavior to be the bug.

Maybe, but then it shouldn't escape the $ either, as the OP is reporting for 
4.2 (I don't have a 4.2 handy to test it).

-- 
D.

Re: Strange bug in arithmetic function

[Davide Brini]

On Monday 21 Feb 2011 09:13:54 Marcel de Reuver wrote:
 In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if
 the week number is even.
 Only in week 08 the error is: bash: 08: value too great for base
 (error token is 08) the same in week 09, all others are Ok...

It's not a bug. First, you shouldn't use the ancient and deprecated $[ .. ] 
syntax for arithmetic evaluation; use $(( .. )).

Second, bash interprets numbers with leading zeros as octal, thus 08 isn't a 
valid octal number. You can force it to be interpreted as decimal by 
prepending the base, eg see

$ echo $(( 08 + 2 ))
-su: 08: value too great for base (error token is 08)

$ echo $(( 10#08 + 2 ))
10

-- 
D.

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

[Davide Brini]

On Thu, 17 Feb 2011 22:35:31 +0800
Clark J. Wang dearv...@gmail.com wrote:

 On Thu, Feb 17, 2011 at 9:20 PM, Andreas Schwab
 sch...@linux-m68k.orgwrote:
 
  Clark J. Wang dearv...@gmail.com writes:
 
   See following script output:
  
   bash-4.2# cat quoted-pattern.sh
   [[ .a == \.a* ]]  echo 1  # not quoted
   [[ aa =~ \.a* ]]  echo 2  # quoted
  
   [[ aa =~ \a.  ]]  echo 3  # not quoted
   [[ aa =~ \a\. ]]  echo 4  # quoted
   bash-4.2# bash42 quoted-pattern.sh
   1
   3
   bash-4.2#
  
   From my understanding 1 2 3 4 should all be printed out.
 
  aa contains no period, so why should it be matched?
 
 
 If it should not be matched why I got 3 printed out?

You're regexp matching aa against a. (I believe the spurious backslash
is ignored), which of course results in a match.

As in:

$ echo aa | grep -E 'a.'
aa

-- 
D.

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

[Davide Brini]

On Thu, 17 Feb 2011 22:56:21 +0800
Clark J. Wang dearv...@gmail.com wrote:

 On Thu, Feb 17, 2011 at 7:09 PM, Clark J. Wang dearv...@gmail.com wrote:
 
  See following script output:
 
  bash-4.2# cat quoted-pattern.sh
  [[ .a == \.a* ]]  echo 1  # not quoted
  [[ aa =~ \.a* ]]  echo 2  # quoted
 
  [[ aa =~ \a.  ]]  echo 3  # not quoted
  [[ aa =~ \a\. ]]  echo 4  # quoted
  bash-4.2# bash42 quoted-pattern.sh
  1
  3
  bash-4.2#
 
  From my understanding 1 2 3 4 should all be printed out.
 
 
 The point is: ``Any part of the pattern may be quoted to force  it  to  be
 matched  as  a string.'' And backslash is one of bash's quoting chars. But
 in my examples, a pattern with `\' in it sometimes is considered to be
 quoted and sometimes unquoted. It's not clear to me what's the exact rule
 to tell if a pattern is quoted or not.

In your first case, the dot is quoted (and taken literally). The lhs is .a
(literal), so overall you have a match.

Second case: again you're quoting the dot, but the lhs now is aa, which
doesn't match dot followed by a followed by any number of characters, so
no match.

Third case: you're quoting a (which wouldn't need to be quoted because
it's not special, but then the backslash is discarded). The dot however is
not quoted, so it has the usual regexp meaning of any character. Thus
aa matches the regular expression pattern a..

Fourth case: you're quoting both the a and the dot, which makes the
patter to match against literally a followed by dot. The input is aa,
which doesn't match.

Hope this helps.

-- 
D.

Re: Why sh does not return a false value?

[Davide Brini]

On Sat, 5 Feb 2011 16:17:05 +0330
ali hagigat hagigat...@gmail.com wrote:

 if (sh -c exit 34) then echo p;fi
 p
 The following condition should be false, because our exit value is
 non-zero. but 'if' considers the condition as true and executes 'echo'
 command. Why?

Try

if (sh -c 'exit 34') then echo ; fi 

and read about the -c option in the man page.

-- 
D.

Re: question about exit command

[Davide Brini]

On Wednesday 19 Jan 2011 10:42:21 ali hagigat wrote:

 I have two script files and I execute them as follows:
 -
 #script1
 echo ppp
 exit 0
 echo qqq
 /root ./script1
 ppp
 -
 #script2
 if (exit 0) then
 echo ppp
 fi
 /root ./script2
 ppp
 -
 In script1, when exit executes, it returns and immediately
 shell(/bin/bash) returns too. Why in the second script shell completes
 if command and does not return immediately? In script 2, what will be
 the return value of shell? The option of exit or the return value of
 echo?

In your second script, the exit 0 part runs in a subshell, so exit exits 
that subshell (and I'm somewhat surprised that no semicolon is required after 
the closing bracket, but I may have missed something in the grammar). Try 
this:

if exit 0; then
  echo ppp
fi

-- 
D.

Re: How is $string translated?

[Davide Brini]

On Mon, 30 Aug 2010 14:30:45 +0300 Pierre Gaston pierre.gas...@gmail.com
wrote:

 On Mon, Aug 30, 2010 at 1:35 PM, Clark J. Wang dearv...@gmail.com wrote:
  The Bash manual says:
 
  A double-quoted string preceded by a dollar sign ($) will cause the
  string to be translated according to the current locale.  If the
  current locale is C or  POSIX,  the dollar sign is ignored.  If the
  string is translated and replaced, the replacement is double-quoted.
 
  Anyone can give an example to show how the $string is translated?
 
 see:
 http://mywiki.wooledge.org/BashFAQ/098

Thanks, this is very useful (and shows I misunderstood how it works).

-- 
D.

Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~

[Davide Brini]

On Wednesday 04 Aug 2010 09:06:16 Linda Walsh wrote:
 On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote:
  On Sun, 1 Aug 2010, Linda Walsh wrote:
  I have:
  
  w=/home/law/bin/package: line 5: type: xx: not found
  
  The =~ operator is suppose to use the RH Expr as a ext.-regex.
  
  So why doesn't this match and print not found?
  
  if [[ $w =~ .*not found.* ]]; then echo not found; fi
  
  It prints nothing.  Seems like such a basic concept.   Sorry, this
  newbie needs help on such trivial matters. :-(
  
  When quoted, the right-hand argument is matched as a string, not an
  expression.
 
 So that's how it is...
 
 Aren't single quotes reserved for making things literal, while
 double quotes are used for grouping, yet interpreting what is between them
 (expansions and such).
 
 Is there a reason RH =~ was made inconsistent regarding this practice?
 
 I might note: the man page makes no reference to such heinous behavior,
 leading one me to think I'd use single quotes if I didn't want the
 contents to be 'active'  Though to tell the truth.  Technically, it says:
 
 An additional binary operator, =~, is available, with  the  same
 precedence  as  ==  and  !=.  When it is used, the string to the
 right of the operator is considered an extended regular  expres-
 sion and matched accordingly (as in regex(3)).
 
 I don't see anything about quotes making the =~ operator behave like
 the == operator.   I'm not sure I see the usefulness in that.
 If there is, then is it necessary to  reserving both single and double
 quotes to make =~ behave like ==?

From the Changelog:

This document details the changes between this version, bash-3.2-alpha,
and the previous version, bash-3.1-release.
...
3.  New Features in Bash
...
f.  Quoting the string argument to the [[ command's  =~ operator now forces
string matching, as with the other pattern-matching operators.


From the file COMPAT:

33. Bash-3.2 adopts the convention used by other string and pattern matching
operators for the `[[' compound command, and matches any quoted portion
of the right-hand-side argument to the =~ operator as a string rather
than a regular expression.

34. Bash-4.0 allows the behavior in the previous item to be modified using
the notion of a shell `compatibility level'.



Finally, to set a given compatibility level, one uses 

shopt -s compat31

This is in the man page:

compat31
If set, bash changes its behavior to that of version 3.1 with respect
to quoted arguments to the conditional command's =~ operator.

So your example would have worked with shopt -s compat31.

-- 
D.

Re: The usage of [[ (not with if)

[Davide Brini]

On Wednesday 04 Aug 2010 16:03:25 Peng Yu wrote:
 
 I have the following script and output. The man page says Return  a
 status  of  0 or 1 depending on the evaluation of the conditional
 expression expression. Therefore, I thought that the two printf
 statements should print 1 and 0 respectively. But both of them print
 0. I'm wondering what [[ should return if it is not used with a if
 statement.
 
 $ cat main.sh
 #!/usr/bin/env bash
 
 printf '%d\n' `[[ 10 -gt 1 ]]`
 printf '%d\n' `[[ 1 -gt 10 ]]`
 if [[ 10 -gt 1 ]]
 then
   echo xxx
 fi
 $ ./main.sh
 0
 0
 xxx

You're confusing return value of the command with output of the command.

-- 
D.