Re: error message lacks useful debugging information

[Dave Cigna via Bug reports for the GNU Bourne Again SHell]

I want to thank all of you for taking this issue seriously. I'm sure you 
all agree that when something fails, the error message should provide 
useful information about what went wrong.


If bash simply doesn't have the information because the kernel didn't 
provide it, then perhaps I should throw this to the kernel developers.


I understand that it might not seem like a bug in the usual sense, but I 
hope that you agree that it's something straddling the line between bug 
and "issue" and really is worth fixing. I don't want to get on a 
soapbox, but it's an example of why linux hasn't acquired the share of 
desktop users that it should.


Thank you again for your time.

David Cigna

On 10/5/23 01:04, Phi Debian wrote:


Since we are on the error path (not the perf path) may be the shell 
could go the extra miles and try some more diag, has it does for 
shebang, on ENOENT, the shell could try to open the a.out, if OK try 
some other euristics, at least the trivial one i.e the multilib case 
that seems the most disorientating one, the wrong arch (arm on intel) 
is already correctly handled, then 'may be' try an ldd (if ldd exist) 
to mention possible missing libs, all this leading to yet another 
'error message' to be entered in the NLS...



Or simply a reword of the current implementation
bash: ./Candle: cannot execute: required file not found
bash: ./Candle: cannot execute: Possible arch mismatch or missing 
shared libs


Assuming no QA test already match the "required file not found", if so 
it would require yet another compat flag...
With this more explicit error message the OP at least have some clue 
to of what to look for.

error message lacks useful debugging information

[Dave Cigna via Bug reports for the GNU Bourne Again SHell]

From: daveci...@misguidedmonkey.net
To: bug-bash@gnu.org
Subject: error message lack useful debuggong information

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux sokoke 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.38-1 (2023-07-14) x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:

Attempting to tun an executable file (not a bash script) with the following
command:

./Candle

the following error message is reported by bash:

bash: ./Candle: cannot execute: required file not found

The executable file 'Candle' does exist in the current directory;
if it didn't then bash would report a different error.

The problem may be a missing dependency. However, the BUG is in bash in that
it doesn't offer any useful debugging information. Debugging the issue could
go from "nearly hopeless" to "I think I can handle this" if bash simply
reported what required file was missing. i.e. path and filename.

Repeat-By:

Here's how I encountered the problem. You might not be able to reproduce
it on your machine, but that doesn't mean that it's not a bug with bash:

download:  candle_1.1.7.tar.gz
from: https://github.com/Denvi/Candle
Extract to the folder of your choosing. cd to that folder and execute the
bash command:

./Candle
From: daveci...@misguidedmonkey.net
To: bug-bash@gnu.org
Subject: error message lack useful debuggong information

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux sokoke 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.38-1 (2023-07-14) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 15
Release Status: release

Description:

Attempting to tun an executable file (not a bash script) with the following
command:

./Candle

the following error message is reported by bash:

bash: ./Candle: cannot execute: required file not found

The executable file 'Candle' does exist in the current directory; 
if it didn't then bash would report a different error.

The problem may be a missing dependency. However, the BUG is in bash in that
it doesn't offer any useful debugging information. Debugging the issue could
go from "nearly hopeless" to "I think I can handle this" if bash simply 
reported what required file was missing. i.e. path and filename.

Repeat-By:

Here's how I encountered the problem. You might not be able to reproduce 
it on your machine, but that doesn't mean that it's not a bug with bash:

download:  candle_1.1.7.tar.gz
from: https://github.com/Denvi/Candle
Extract to the folder of your choosing. cd to that folder and execute the
bash command:

./Candle

Re: BASH_XTRACEFD=1 read variable stdout flushing?

[Dave Drambus]

Thanks for the explanation and the help!

On Mon, Jan 16, 2023 at 1:53 PM Chet Ramey  wrote:

> On 1/16/23 12:36 PM, dave.dram...@gmail.com wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
> -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
> -Wall
> > uname output: Linux sulfur 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5
> 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> > Machine Type: x86_64-pc-linux-gnu
> >
> > Bash Version: 5.1
> > Patch Level: 16
> > Release Status: release
> >
> > Description:
> >
> >   I have `set -x` and `BASH_XTRACEFD=1` set in a simple script that
> I have in
> >   a cron job. I'd like to see the progress of the script when run
> manually,
> >   hence `set -x`, but I want the output to go to stdout rather than
> stderr so
> >   that cron emails me only when there is an actual failure. With this
> >   configuration, the `read` command is erroneously reading the "+"
> prompt
> >   output from `set -x` into the variable. It seems like stdout is
> not getting
> >   flushed propertly.
> >
> > Repeat-By:
> >   The following script attempts to read the first column of data,
> line by
> >   line, into a variable called `$var`. With `BASH_XTRACEFD` unset, it
> >   propertly prints r1c1, r2c1, r3c1, r4c1. With `BASH_XTRACEFD=1`,
> `$var`
> >   gets set to +, ++, r2c1, r3c1, r4c1. Maybe I am just being dumb?
> >
> > ```
> > #!/usr/bin/env bash
> >
> > BASH_XTRACEFD=1
> > set -x
> >
> > data=$(cat << END
> > r1c1r1c2r1c3\n
> > r2c1r2c2r2c3\n
> > r3c1r3c2r3c3\n
> > r4c1r4c2r4c3
> > END
> > )
> >
> > echo -e $data | while read -r var junk; do
> >  echo "var = $var"
> > done
> > ```
>
> As you discovered, BASH_XTRACEFD makes the xtrace output write to the
> designated file descriptor. If you write to fd 1, you're going to write the
> trace output into the pipe, where `read' will see it.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>

BASH_XTRACEFD=1 read variable stdout flushing?

[dave . drambus]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall 
uname output: Linux sulfur 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:

I have `set -x` and `BASH_XTRACEFD=1` set in a simple script that I 
have in
a cron job. I'd like to see the progress of the script when run 
manually,
hence `set -x`, but I want the output to go to stdout rather than 
stderr so
that cron emails me only when there is an actual failure. With this
configuration, the `read` command is erroneously reading the "+" prompt
output from `set -x` into the variable. It seems like stdout is not 
getting
flushed propertly.

Repeat-By:
The following script attempts to read the first column of data, line by
line, into a variable called `$var`. With `BASH_XTRACEFD` unset, it
propertly prints r1c1, r2c1, r3c1, r4c1. With `BASH_XTRACEFD=1`, `$var`
gets set to +, ++, r2c1, r3c1, r4c1. Maybe I am just being dumb?

```
#!/usr/bin/env bash

BASH_XTRACEFD=1
set -x

data=$(cat << END
r1c1r1c2r1c3\n
r2c1r2c2r2c3\n
r3c1r3c2r3c3\n
r4c1r4c2r4c3
END
)

echo -e $data | while read -r var junk; do
echo "var = $var"
done
```


Fix:
[Description of how to fix the problem.  If you don't know a
fix for the problem, don't include this section.]

Cygwin bash build- command substitution fails

[Dave Taylor]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS   -I.
 -I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib  -DWORDEXP_OPTION -ggdb
-O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3
-Wno-parentheses -Wno-format-security
uname output: CYGWIN_NT-10.0 ddtlap 3.0.7(0.338/5/3) 2019-04-30 18:08
x86_64 Cygwin
Machine Type: x86_64-unknown-cygwin

Bash Version: 4.4
Patch Level: 12
Release Status: release

Description:
I'm trying to do a Cygwin build of the bash git repo at bminor/bash on
github.

The configure (no options) and make (no options) finish successfully, but
the build fails when doing $()-style command substitutions, claiming that
the trailing paren is unexpected:

% echo $(echo hiya)
bash: command substitution: line 9: syntax error near unexpected token `)'
bash: command substitution: line 9: `echo hiya)'
%

Note that other approaches to command substitution seem to work:

% echo $(echo hiya
> )
hiya
%

% echo `echo hiya`
hiya
%

Repeat-By:

Install cygwin (ver 3.1.0-1)
Install cygwin-devel (ver 3.1.0-1)
Install autoconf2.5 (ver 2.69-4)
Install autoconf (ver 13-1)
git clone https://github.com/bminor/bash.git
cd bash
./configure
make
./bash
echo $(echo hiya)

Re: Could bash do what make does?

[Dave Finlay]

There is an onus on you to use the appropriate mailing list. Bug-bash isn't
for make-ing your case, bug-bash is for the bugs.

Dave Finlay

On Dec 6, 2016 15:44, "Robert Durkacz" <robert.durk...@gmail.com> wrote:

On 6 December 2016 at 00:19, Greg Wooledge <wool...@eeg.ccf.org> wrote:

>  what evidence?
> ​ [for shell scripting builds]
>
​
I suppose the evidence that you want is in the very same wikipedia article
about make, where it says precisely that shell scripts were used before
make came along.
However, please remember I am here asking a question. I am not promoting
any views about these matters which are secondary to the question. There is
no onus on me to prove anything. If you are interested in my views and I
doubt you are, you can email me privately. I will not indulge you in
further public exchanges no matter how provocative you try to be. "Put up
or shut up" indeed.

Re: Could bash do what make does?

[Dave Finlay]

Robert-

I wanted to craft a witty retort with a veneer of encouragement that might
push your towards trying your proposed endeavor.  I could not bring myself
to do it after realizing that you are quite serious.  I understand your
motivations.  Build systems are often complicated, opaque pieces of
software with many bespoke elements, like syntax, configuration, and macro
systems.  They often become that way because software projects of any large
size start to take on their own arbitrary conventions and requirements that
must be handled.  We just love to shoot ourselves in the foot.

I feel like these are self evident, but perhaps there is a grok gap I'm not
seeing. Bash is a shell, a language and an old friend. It is not a build
system. Narrowing and/or expanding a piece of software's scope to address
problems it isn't concerned with is almost always going to end in tears.
See the Unix Philosophy
<https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well>:
do one thing and do it well.

I recommend you attempt this endeavor independently, as a learning
experience. Try writing a script and a function library that will allow you
to build the Bash project (or something simpler) without Make or Autotools.
You will come to understand why the world is as it is.  You will come to
truly comprehend the dark side of dealing with compilation caches, diverse
compiler output, job control, dependency management, packaging, and all the
other painful things.

After that exercise, take a look at some of approaches people have taken.
CMake, Maven, Gradle, and SCons are good projects to look at. Just take a
look at how much thought went into Maven's Dependency Version Requirement
Specification
<https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification>.
There is no magic that will lead to the 'Perfect Build System'.  It takes
well thought out architecture, obsession with details, and a gobs of
effort.  Even with all that, it will never be perfect or universal.  There
is always a use case or edge case you didn't deal with.

I hope this response was of benefit to you.



Dave Finlay

On Fri, Dec 2, 2016 at 2:29 AM, Robert Durkacz <robert.durk...@gmail.com>
wrote:

> I agree that is the first step to take, but I am supposing that, since
> build systems are a big business, some extensions to bash would be worth
> doing to take on that market. E.g. I think we would need a concept of lists
> of files so as to skip executing a command if all files in the list are
> older than some file that is required.
>
> On 29 November 2016 at 02:21, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
>
>>
>>
>> On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz <robert.durk...@gmail.com
>> > wrote:
>>
>>> Has thought been given, over the years, to extending bash to do
>>> what make does, in the obvious way that I am about to describe?
>>>
>>> It would be a matter of having chosen build commands do nothing if their
>>> outputs are newer than their inputs. For example that is, cc file.c -o
>>> file.o should execute normally if file.c is the newer file but do nothing
>>> if file.o is newer.
>>>
>>> Then you would have a deterministic script to build a system that simply
>>> skipped steps determined to be unnecessary.
>>>
>>> It is possible to achieve this without changing bash but it seems like
>>> there would be leverage in having bash deliberately support this mode.
>>>
>>
>>
>> Use the newer-than test:
>>
>> source=file.c
>> object=file.o
>> [[ $source -nt $object ]] && cc "$source" -o "$object"
>>
>>
>> --
>> Visit serverfault.com to get your system administration questions
>> answered.
>>
>
>

Re: copy

[Dave Finlay]

Does the /data/test directory exist prior to execution?  Otherwise cp is
just copying the result set one at a time to a regular file at /data/test.

You may want to append a forward slash to the directory name, as that will
cause cp to error if the directory doesn't exist instead.  Or chain the
command after mkdir -p /output/dir.  That will error the same if it isn't a
directory, but also create it if it doesn't exist.  Since you are
interested in the files' timestamps, you may way to use --preserve to
preserve them.

So, something like this:

dest_dir='/data/test'; mkdir -p "${dest_dir}" && find . -type f -mtime +10
-name "*.txt" -exec cp --preserve {} "${dest_dir}" \;



Dave Finlay

On Thu, Feb 25, 2016 at 5:41 PM, Val Krem <valk...@yahoo.com> wrote:

> Hi,
>
> I want to copy files which are older than 10 days  with the extension file
> name txt.
>
>
> I used the following  and it is not doing what supposed to do
>
>
> find . -type f -mtime +10 -name "*.txt" -exec cp {} /data/test \;
>
> can any one help me out?
>
>

Re: bug when 'cd ..' to a directory who's parent has been deleted

[Dave Rutherford]

On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh <b...@tlinx.org> wrote:
> Chet Ramey wrote:
>> On 2/8/16 9:59 AM, Andreas Schwab wrote:
>>> Chet Ramey <chet.ra...@case.edu> writes:
>>>> `cd ..' should fail, since the parent no longer exists, and the
pathname
>>>> canonicalization should fail, since there's presumably no longer a
valid
>>>> path to reach the current directory.  No value for $PWD is correct.
>>> ${PWD%/*} would be a reasonable value.  FWIW, this is what ksh uses in
>>> this case, it doesn't fail.
>> Why would that be more reasonable than anything else?  It references a
>> path that doesn't exist.
> Um...Not exactly.  As long as there's a handle open to the previous path,
> it still exists (at least on linux and unix).

Really?
11:40:24 dave@Vger:~$ mkdir -p a/a
11:40:30 dave@Vger:~$ cd a/a
[remove a in another window]
11:40:49 dave@Vger:~/a/a$ touch file
touch: cannot touch ‘file’: No such file or directory

Re: Future date

[Dave Rutherford]

On Sun, Jan 24, 2016 at 5:30 PM, Val Krem  wrote:
> I am trying to get a variable that combines the next month(Feb) and
current  year (2016) from the current date
[...]
> temp_date=$(date | awk -F ' ' '{print $2,$6}' | tr  -d ' ')

Wow, that's overkill. You don't need the -F ' ' options to awk, since
that's the default. You don't need tr to remove the space because
awk will happily not print one if you omit the comma.

And you don't need awk in the first place because date will handle
the desired output directly if you just ask it to.

> I got  Jan2016.
> but I want  this "Feb2016" next month and current year. How do I do that?
>
> Well at the end of the year, I will have another problem ( ie., to change
it to next year)

date -d 'next month' +%b%Y

Note, I'm not sure that's robust if you call it on, say, the 31st of the
month
if the next month doesn't have 31 days. It might give you two months from
now.
Read the man page for date for further enlightenment.

Re: why must bash zap last search string just because we hit ^C?

[Dave Rutherford]

On Sat, Oct 17, 2015 at 11:19 PM, 積丹尼 Dan Jacobson 
wrote:

> > "DW" == Dennis Williamson  writes:
>
> DW> Or just open a new terminal rather than interrupting an in-progress
> search.
>
> I am on a device where opening a new terminal is a lot of trouble.
>

Can you run gnu screen? ^A-c will get you a new shell session in the
existing terminal emulator (it will use a new terminal device, though,
if that's what you care about.)

Re: remaking bash, trying static, glibc refuses static...?

[Dave Rutherford]

On Wed, Aug 19, 2015 at 5:55 PM, Linda Walsh b...@tlinx.org wrote:
[cut a lot about dynamic linking and the linux kernel]
 Even bash can load many of it's builtin's dynamically -- but if they
 aren't there, it could use the same named-programs -- and I don't
 think it falls-over and dies if it can't dynamically load a builtin --
 it just looks for the same name in the path.

There are loadable builtins but I don't believe it is true that they
can magically self-load as you describe. The closest this comes
to the truth is that many builtins have corresponding programs
in /bin, for the use of programs that don't have them builtin or
for entities that might naïvely search the PATH looking for things
which are legal to execute. (Some unices even include a /bin/cd
for that reason, as pointless as that would otherwise be.)

Did the rest of your message have anything to do with bash?
You were trying to build a static version... you've been told how...
was there more?

Re: eval a=b\ c

[Dave Yost]

OK, I can make it to work in bash if I say
  echodo a=b\\ c
but then zsh tries to execute c. Can’t win.

The problem is: how do I write this function so that it can be invoked 
identically in zsh and bash with identical results of setting a variable to a 
value with a space in it?

 On 2015-05-26, at 1:04 AM, Andreas Schwab sch...@suse.de wrote:
 
 d...@yost.com writes:
 
eval$@
 
 You are expanding a shell parameter unquoted.  Never do that unless you
 know what you are doing.
 
  eval $@
 
 Andreas.
 
 -- 
 Andreas Schwab, SUSE Labs, sch...@suse.de
 GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
 And now for something completely different.


On 2015-05-25, at 6:12 PM, Dennis Williamson dennistwilliam...@gmail.com 
wrote:

 I'm trying to put a command in a variable, but the complex cases always fail! 
 : http://mywiki.wooledge.org/BashFAQ/050
 
 Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048
 
 On Mon, May 25, 2015 at 2:33 PM,  d...@yost.com wrote:
 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/local/bash/4.3.39/share/locale' 
 -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I../bash-4.3 
 -I../bash-4.3/include -I../bash-4.3/lib   -g -O2
 uname output: Linux s6.millcomputing.com 2.6.32-504.16.2.el6.x86_64 #1 SMP 
 Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 Machine Type: x86_64-unknown-linux-gnu
 
 Bash Version: 4.3
 Patch Level: 39
 Release Status: release
 
 Description:
 
 # Echo the arguments, then execute them as a command.
 function echodo() {
   if [[ -n $ZSH_VERSION ]] ; then
 echo [ ${(q)@} ]
 eval${(q)@}
   else
 echo [ $@ ]
 eval$@
   fi
 }
 echodo echo b\ c
 echodo a=b\ c
 echo $a
 
 The result in zsh is:
   $ echodo echo b\ c
   [ echo b\ c ]
   b c
   $ echodo a=b\ c
   [ a=b\ c ]
   $ echo $a
   b c
   $
 
 Bash gets an error:
   $ echodo echo b\ c
   [ echo b c ]
   b c
   $ echodo a=b\ c
   [ a=b c ]
   bash: c: command not found
   $ echo $a
 
   $
 
 I can't find a way to implement echodo in bash. Apparently this is because 
 bash is unable to expand a variable with quoting intact, as zsh can do with 
 its (q) expansion flag.
 
 Bash behaves differently in this case::
 
   $ echodo export a=b\ c
   [ export a=b c ]
   $ echo $a
   b
   $
 
 
 Repeat-By:
 
 
 
 Fix:
 
 
 
 
 -- 
 Visit serverfault.com to get your system administration questions answered.
 

eval a=b\ c

[dave]

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/local/bash/4.3.39/share/locale' 
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I../bash-4.3 
-I../bash-4.3/include -I../bash-4.3/lib   -g -O2
uname output: Linux s6.millcomputing.com 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed 
Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.3
Patch Level: 39
Release Status: release

Description:

# Echo the arguments, then execute them as a command.
function echodo() {
  if [[ -n $ZSH_VERSION ]] ; then
echo [ ${(q)@} ]
eval${(q)@}
  else
echo [ $@ ]
eval$@
  fi
}
echodo echo b\ c
echodo a=b\ c
echo $a

The result in zsh is:
  $ echodo echo b\ c
  [ echo b\ c ]
  b c
  $ echodo a=b\ c
  [ a=b\ c ]
  $ echo $a
  b c
  $

Bash gets an error:
  $ echodo echo b\ c
  [ echo b c ]
  b c
  $ echodo a=b\ c
  [ a=b c ]
  bash: c: command not found
  $ echo $a
  
  $

I can't find a way to implement echodo in bash. Apparently this is because bash 
is unable to expand a variable with quoting intact, as zsh can do with its (q) 
expansion flag.

Bash behaves differently in this case::

  $ echodo export a=b\ c
  [ export a=b c ]
  $ echo $a
  b
  $


Repeat-By:



Fix:

Re: [Bug-readline] Problem with CTRL-z and readline()

[Dave Wysochanski]

On Sun, 2015-03-01 at 20:14 -0500, Chet Ramey wrote:
 On 2/27/15 12:10 PM, Dave Anderson wrote:
  
  This issue was first reported with respect to the crash utility,
  which is an interactive program that uses the readline library.  
  
  The problem occurs only if the crash utility is run from within 
  an executable bash script, i.e., like so:
  
$ cat doit
crash
$
  
  If crash is invoked as above, the crash utility does its initialization
  and eventually calls readline().  Then, if CTRL-z is entered, the parent 
  bash shell itself is blocked, but the crash utility spins at 100% cpu usage.
  Debugging it shows that the crash utility is stuck spinning in the readline
  libary's _set_tty_settings() function, where the tcsetattr() call repeatedly
  fails with an EINTR, where _rl_caught_signal contains SIGTTOU.  
  
  But taking the crash utility out of the picture, I can reproduce it with
  readline-6.3.tar.gz, where I simply build it with configure; make, then 
  go into the examples subdirectory, and enter make.  If I then put the
  simple rl command in script file, and do the same thing, this happens:
  
$ cat doit
./rl
$ ./doit
readline$ ^Z
[1]+  Stopped ./doit
$
$ top
top - 12:02:33 up 23:12,  5 users,  load average: 0.37, 0.09, 0.04
Tasks: 159 total,   2 running, 154 sleeping,   3 stopped,   0 zombie
Cpu(s):  3.4%us, 21.6%sy,  0.0%ni, 75.0%id,  0.0%wa,  0.0%hi,  0.0%si,  
  0.0%st
Mem:   3917056k total,  3709052k used,   208004k free,88732k buffers
Swap:  4063228k total,0k used,  4063228k free,  3049316k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  
  
12336 root  20   0  100m 1016  788 R 100.0  0.0   1:12.13 rl
1 root  20   0 19356 1532 1216 S  0.0  0.0   0:02.89 init
2 root  20   0 000 S  0.0  0.0   0:00.02 kthreadd
3 root  RT   0 000 S  0.0  0.0   0:00.19 migration/0
...
  
 
  If I attach gdb to the rl process above, it shows the same ultimate trace as
  the spinning crash utility does:
  
# gdb -p 12336
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 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.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Attaching to process 12336
Reading symbols from /root/readline-6.3/examples/rl...done.
Reading symbols from /lib64/libtinfo.so.5...Reading symbols from 
  /usr/lib/debug/lib64/libtinfo.so.5.7.debug...done.
done.
Loaded symbols for /lib64/libtinfo.so.5
Reading symbols from /lib64/libc.so.6...Reading symbols from 
  /usr/lib/debug/lib64/libc-2.12.so.debug...done.
done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
  /usr/lib/debug/lib64/ld-2.12.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0033f52dff48 in tcsetattr (fd=0, optional_actions=value optimized 
  out, termios_p=0x62cb60)
at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
84  retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, k_termios);
(gdb) bt
#0  0x0033f52dff48 in tcsetattr (fd=0, optional_actions=value 
  optimized out, termios_p=0x62cb60)
at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
#1  0x00406f8d in _set_tty_settings (tty=0, tiop=0x62cb60) at 
  rltty.c:476
#2  0x00406fe3 in set_tty_settings (tty=value optimized out, 
  tiop=value optimized out) at rltty.c:490
#3  0x004072d0 in rl_deprep_terminal () at rltty.c:688
#4  0x00413352 in rl_cleanup_after_signal () at signals.c:536
#5  0x00413731 in _rl_handle_signal (sig=20) at signals.c:232
#6  0x004137e5 in _rl_signal_handler (sig=value optimized out) 
  at signals.c:155
#7  0x00415575 in rl_getc (stream=0x33f558e6c0) at input.c:480
#8  0x00415a60 in rl_read_key () at input.c:462
#9  0x0040340d in readline_internal_char () at readline.c:564
#10 0x004037d3 in readline_internal_charloop (prompt=value 
  optimized out) at readline.c:629
#11 readline_internal (prompt=value optimized out) at readline.c:643
#12 readline (prompt=value optimized out) at readline.c:369
#13 0x004025b6 in main (argc=1, argv=0x7fff0af285d8) at rl.c:149
(gdb) 
(gdb) c
Continuing.

Program received signal SIGTTOU, Stopped (tty output).
0x0033f52dff48 in tcsetattr (fd=0, optional_actions=value optimized

Re: Memory leak in wait

[Dave Rutherford]

On Mon, Mar 2, 2015 at 2:33 AM, Jean Delvare jdelv...@suse.de wrote:
 Which brings another question: is there any plan to implement sleep as
 a bash builtin?

It's already available as a loadable builtin (examples/loadables/sleep.c).

Re: Tab completion breaks for tilde-paths with filenames containing space

[Dave Rutherford]

On Wed, Jan 14, 2015 at 9:45 AM, Eduardo A. Bustamante López
dual...@gmail.com wrote:
 On Wed, Jan 14, 2015 at 09:33:31AM -0500, d...@evilpettingzoo.com wrote:
 [...]
 Bash Version: 4.2
 Patch Level: 37

Also tested on 4.3.30

 [dualbus@dualbus ~]$ mkdir a; a/a\ a.txt

You didn't create any ambiguity there. It seems to be a partial requirement.

 [dualbus@dualbus ~]$ echo ~/a/aTAB [completes]
 [dualbus@dualbus ~]$ echo ~/a/a\ a.txt
 /home/dualbus/a/a a.txt
 [dualbus@dualbus ~]$ echo ~/a/a\ aTAB [completes]
 [dualbus@dualbus ~]$ echo ~/a/a\ a.txt
 /home/dualbus/a/a a.txt

 Are you using any supplementary programs, like bash-completion?

I don't think so, unless Debian turned it on for me.

Note that without a\ a.odt there,
$ ls ~/a/aTAB[completes to a\ a.txt]
but
$ ls ~/a/a\ TAB  [does not complete]

Tab completion breaks for tilde-paths with filenames containing space

[dave]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
uname output: Linux bb 3.2.60dr #1 SMP Fri Oct 3 14:41:46 EDT 2014 x86_64 
GNU/Linux
Machine Type: x86_64-pc-linux-gnu

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

Description:
Pathnames starting with tilde, combined with filenames containing 
space, only partially tab-complete.

Repeat-By:
$ cd
$ mkdir a
$ touch a/a\ a.txt a/a\ a.odt
$ vi a/aTAB   [correctly completes to]
$ vi a/a\ a.TAB
a a.ods  a a.txt
^C
$ vi ~/a/aTAB [correctly completes to]
$ vi ~/a/a\ a.TAB [further tabs do nothing]
$ vi ~/a/a\ a.tTAB[still nothing]

Re: Tab completion breaks for tilde-paths with filenames containing space

[Dave Rutherford]

On Wed, Jan 14, 2015 at 10:14 AM, Eduardo A. Bustamante López
dual...@gmail.com wrote:
 Can you test with:
  bash --norc --noprofile -i

It is working in this case. The difference seems to be in direxpand.

$ shopt -s direxpand; shopt direxpand
direxpand   on
$ vi ~/a/a\ TABTAB[nothing]
$ shopt -u direxpand; shopt direxpand
direxpand   off
$ vi ~/a/a\ TAB   [expands to]
$ vi ~/a/a\ a.TABTAB
a a.odt  a a.txt

Is this expected?

Re: bash-2.05b-013 appears to not work

[Dave Kalaluhi]

I guess that would help. I meant to include that in the initial mail,
but alas, running in 50K directions.

Locally we are using:

(for x in {1..200} ; do echo for x$x in ; do :; done; for x in
{1..200} ; do echo done ; done) | bash ||
echo CVE-2014-7187 vulnerable, word_lineno

If we run the test via ssh, it is showing patched, however locally is
still showing vulnerable.

Thanks Eric,
Dave

On 10/16/14, Chet Ramey chet.ra...@case.edu wrote:
 On 10/16/14, 5:02 PM, Dave Kalaluhi wrote:
 We have been compiling some of the older versions of bash to fix
 vulnerabilities, and for the most, has been working.

 However, when we patch the 013 patch for CVE-2014-7187, and run the
 nested loop, it's still showing as vulnerable.

 Has anyone else had a similiar experience?

 Since the code that had the off-by-one error was not even in bash-2.05b,
 I'm skeptical that it's vulnerable.

 --
 ``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-2.05b-013 appears to not work

[Dave Kalaluhi]

Awesome - Thanks everyone for the help! I will forward these responses
on to the security group. But again, Thank you everyone!!!

-Dave

On 10/17/14, Andreas Schwab sch...@linux-m68k.org wrote:
 Eric Blake ebl...@redhat.com writes:

 The following is a better test for whether CVE-2014-7187 can be
 exploited to remotely attack your system:

 f='() { echo vulnerable; } bash -c f

 Missing quote character.

 f='() { echo vulnerable; }' bash -c f

 Andreas.

 --
 Andreas Schwab, sch...@linux-m68k.org
 GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
 And now for something completely different.

bash-2.05b-013 appears to not work

[Dave Kalaluhi]

We have been compiling some of the older versions of bash to fix
vulnerabilities, and for the most, has been working.

However, when we patch the 013 patch for CVE-2014-7187, and run the
nested loop, it's still showing as vulnerable.

Has anyone else had a similiar experience?

Thanks for the help,
D

Re: bash uses tmp files for inter-process communication instead of pipes?

[Dave Rutherford]

On Tue, Oct 7, 2014 at 2:25 AM, Dave Rutherford d...@evilpettingzoo.com
wrote:
**it.. sorry for the fat finger post. Gmail puts the tiny formatting options
right next to the big SEND button. Ratzen fracken.

Re: bash-4.3 bug report

[Dave Rutherford]

On Mon, Apr 14, 2014 at 12:22 PM, David Binderman dcb...@hotmail.com wrote:
 Anyone experienced looking at the code will always need to examine it
 more closely to find out why it's a good idea in this case to use an array
 index and *then* sanity check it's value.

But in this case it's a limiting check, not a bounds check,
and having it second helps to make this clear. I agree that
the bug lies in the static analyzer.

Re: When a hashed pathname is deleted, search PATH

[Dave Rutherford]

On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey chet.ra...@case.edu wrote:
 On 3/15/14 2:44 PM, Reuben Thomas wrote:
 On 15 March 2014 18:23, Chet Ramey chet.ra...@case.edu
 mailto:chet.ra...@case.edu wrote:
 Is there a downside to making checkhash the default?

 Only the minor performance hit it would extract on every command lookup.

Only on commands that were found in the hash table, correct?
This is not a minor performance hit, but a trivial one. Consider
this my vote for checkhash as the default.

Dave

RFE: a way to echo the arguments with quoting

[Dave Yost]

I have an ugly function I wrote for zsh that does this:

Sat 14:17:25 ip2 yost /Users/yost
1 634 Z% echo-quoted xyz \$foo  'a b c ' '\n'
xyz '$foo' 'a b c ' '\n'
Sat 14:17:53 ip2 yost /Users/yost
0 635 Z% 

It would be nice if there were an easy way to do this in bash.

Here is my use case:

echo-command() {
echo-n 12 [ 
echo-quoted -n 12$@
echo   12  ]
}

echodo() {
echo-command $@
eval $@
}

1 652 Z% echodo sleep 1 
[ sleep 1 ]
0 653 Z% 

This is a bit of a hack because when I need to use a pipe character, for 
example, I have to quote it, and that gets echoed in a way that’s wrong for 
this purpose.

0 656 Z% echodo echo abc \| sed 's,b,_,'
[ echo abc '|' sed s,b,_, ]
a_c
0 657 Z% 

A builtin that does my ‘echodo’ without having to escape command-line 
metacharacters is what I really want.

Is there such a thing?

typo in bash manual

[Dave Yost]

In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel

Where you say
ls *.gz | parallel -j+0 zcat {} | bzip2 {.}.bz2  rm {}
This will recompress all files in the current directory with names ending in 
.gz using bzip2, running one job per CPU (-j+0) in parallel.

it should be
ls *.gz | parallel -j+0 zcat {} | bzip2 {.}.bz2  rm {}
This will recompress all files in the current directory with names ending in 
.bz2 using bzip2, running one job per CPU (-j+0) in parallel.


Also, you should mention what the +0 does.

Re: How to test if a link exists

[Dave Gibson]

Mark Young marky1...@gmail.com wrote:

 A little off topic but are -a and -e identical?

As file existence tests, yes.  -a also serves as logical and.

Re: How to test if a link exists

[Dave Gibson]

Mark Young marky1...@gmail.com wrote:
 Hi,
 
 I stumbled into discovering that the -e test for a file does not
 report the file as existing if the file is a dead symbolic link.

It's documented in the bash manpage under CONDITIONAL EXPRESSIONS.

   Unless otherwise specified, primaries that operate on files follow sym-
   bolic links and operate on the target of the link, rather than the link
   itself.

 What test should I use to decide if a file exists (including dead
 symbolic links)?

-h and -L apply to the symlink rather than the target, so

  test -e broken_link -o -h broken_link

Re: corrupted input after size function (input that's not recorded by bash)

[Dave Gibson]

Linda Walsh b...@tlinx.org wrote:
 
 I have a small function in my bashrc:
 
 function showsize () {\
   local s=$(stty size); local o=(${s% *}x${s#* }); s=${#o};\
   echo -n $o; while ((s--  0));do echo -ne \b; done; \
 }
 export -f showsize
 trap showsize SIGWINCH
 ---
 That has the effect of showing me my current window size
 when I resize it.
 
 The odd thing is, if I use it while at a bash input prompt --
 any command I type has the first word ignored.

Ignored or executed as a separate command?

Using bash 4.2.45, echo ls / is treated as echo ; ls / although
as you've noticed the command appears in the history as-typed.

 
 so if I type:
 echo cmd
 
 If 'cmd' is not a typo you can use command-not-found to lookup the
 package that contains it, like this:
 cnf cmd
 ---
 But then I re-edit the line (in vi-mode, ESC-k, it shows me I typed
 echo cmd -- and, indeed, if I hit return, it echo's the word 'cmd'
 w/no error.
 
 So how can my showsize function be mangling the input in a way that
 prevents proper execution, but isn't recorded by bash?

Trial and error suggests it's something to do with new-style command
substitution.  Try backticks:

local s=`stty size`

 
 (this has been one of those things that's bothered me for years, but
 never been important enough to even ask about... I thought I'd look at it
 to fix it, but still don't see why it does what it does).
 
 Any clues?

showsize()
{
  local o=(${LINES}x${COLUMNS}) ; local s=${o//?/\\b} ; printf $o$s
}

Re: Behavior of calling return from a trap

[dave reisner]

On Tue, Apr 10, 2012 at 12:04:36PM -0400, Chet Ramey wrote:
 You're calling the error trap twice.  The first time you call it is after
 the `false' in the body of the function, and the `return' works as intended
 there.  Since you return 1, the call to `somefunc' fails, triggering the
 error trap again.  The second time you call it, you're not executing in a
 function context, and `return' throws an error.

Ah, of course. That makes a lot of sense. Thanks for clarifying.

dave

Behavior of calling return from a trap

[dave reisner]

Hi all,

I'm noticing some odd behavior in an ERR trap with errtrace. It's
present in bash 3.2 and as well as 4.2. The simplest reproduction is
as follows:

--8--
#!/bin/bash

somefunc() {
  false
  echo shouldn't see this
}

set -E
trap -- 'return 1' ERR

somefunc
echo should see this
--8--

Both versions of bash throw an error, though fwiw the line number
differs: bash4 blames the line of where the trap is fired versus bash3
which blames the line where the trap is declared. The entire output of
the script is:

foo: line 4: return: can only `return' from a function or sourced
script
should see this

So, both versions give the intended behavior of returning from the
function despite the error. imo, there's a bug here somewhere, I'm
just not sure if it's the faulty error being thrown or if I shouldn't
be expecting the trap to work as it is when it's declared outside of a
function.

Regards,
Dave

Issue with errtrace

[Dave]

Hi all,

Recently upgraded to 3.2 and noticed some differences in a lot of my
scripts, consider the following example:

#!/bin/bash

trap error_reporter ERR
set -o errexit
set -o errtrace
set -o nounset
set -o pipefail
logf_error=/dev/null

function _exit
{
  local -ri retval=${1:-$?}
  exit ${retval}
}

function error_reporter {
  local -ri retval=$?
  #echo Error in script setup. Exiting with error value ${retval}.
  local -i i=0
  #echo Function call stack: 2
  while caller $i 2; do  (( i++ ));  done
  _exit ${retval}

}

function echo_ {  #this is called as a $(command)

#a subcommand might return with 1 in the script, but in most cases it is
not a problem.
#At least in our scripts there are a lot of cases like this where the error
is handled afterwards
echo  | grep b
echo Execution continues
}

echo Turning off errtrace
set +o errtrace
var=$(echo_)#calling as a $(command)
echo $var
echo Turning on errtrace
set -o errtrace

echo Next command will fail in bash3.2
var=$(echo_)#calling as a $(command)
echo $var



Doesnt work right on 3.2


Output from 3.0

root@atrcus365:/# /tmp/test
/tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
Execution continues
root@atrcus365:/# echo $BASH_VERSION
echo $BASH_VERSION
3.00.16(1)-release
root@atrcus365:/#


Output from 3.2

root@atmwsnfd:/# /tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
26 echo_ /tmp/test
42 main /tmp/test
42 main /tmp/test
root@atmwsnfd:/# echo $BASH_VERSION
3.2.51(1)-release
root@atmwsnfd:/#



Could anyone point me in correct direction on this one ?

Regards
Dave

bash 3.2 vs 3.0

[Dave]

Hi all,

Recently upgraded to 3.2 and noticed some differences in a lot of my
scripts, consider the following example:

#!/bin/bash

trap error_reporter ERR
set -o errexit
set -o errtrace
set -o nounset
set -o pipefail
logf_error=/dev/null

function _exit
{
  local -ri retval=${1:-$?}
  exit ${retval}
}

function error_reporter {
  local -ri retval=$?
  #echo Error in script setup. Exiting with error value ${retval}.
  local -i i=0
  #echo Function call stack: 2
  while caller $i 2; do  (( i++ ));  done
  _exit ${retval}

}

function echo_ {  #this is called as a $(command)

#a subcommand might return with 1 in the script, but in most cases it is
not a problem.
#At least in our scripts there are a lot of cases like this where the error
is handled afterwards
echo  | grep b
echo Execution continues
}

echo Turning off errtrace
set +o errtrace
var=$(echo_)#calling as a $(command)
echo $var
echo Turning on errtrace
set -o errtrace

echo Next command will fail in bash3.2
var=$(echo_)#calling as a $(command)
echo $var



Doesnt work right on 3.2


Output from 3.0

root@atrcus365:/# /tmp/test
/tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
Execution continues
root@atrcus365:/# echo $BASH_VERSION
echo $BASH_VERSION
3.00.16(1)-release
root@atrcus365:/#


Output from 3.2

root@atmwsnfd:/# /tmp/test
Turning off errtrace
Execution continues
Turning on errtrace
Next command will fail in bash3.2
26 echo_ /tmp/test
42 main /tmp/test
42 main /tmp/test
root@atmwsnfd:/# echo $BASH_VERSION
3.2.51(1)-release
root@atmwsnfd:/#



Could anyone point me in correct direction on this one ?

Regards
Dave

Re: How to run something before invoking the inputted command?

[Dave Rutherford]

On Mon, Jul 12, 2010 at 08:16, Greg Wooledge wool...@eeg.ccf.org wrote:
 On Sat, Jul 10, 2010 at 11:30 AM, Eric Blake ebl...@redhat.com wrote:
  Not quite before the command, but it is very easy to include $(date) as
  part of PS1 to have a timestamp listed in the prompt that is printed
  after every command.

 On Sat, Jul 10, 2010 at 11:54:05AM +0800, Clark J. Wang wrote:
 Yes, timestamp in PS1 is fine for after-command purposes. And actually I use
 the PROMPT_COMMAND var for that.

 unset PROMPT_COMMAND
 PS1='$(date +%H:%M:%S)|\h:\w\$ '

Why not just use the \t escape in PS1? Or, if you want other
arguments to strftime, you could write \D{%H:%M:%S}.

Re: Failed bash -r command returns 0 exit status

[Dave Rutherford]

On Mon, May 24, 2010 at 02:48, Pitt, David david.p...@anz.com wrote:
        However executing /bin/ls  /bin/ls under a restricted shell
 returns a zero exit
        status. This is not expected (at least not by me!). Zero exit
 status is returned with
        any list of commands, e.g. /bin/ls  :.

That one would, since the second command is 'true'. Replace it
with 'false' and you should see an exit status of 1.

As for /bin/ls  /bin/ls, since neither command runs neither
one fails, either.  'Tis a bit of a head-scratcher, though.

Dave

Re: Failed bash -r command returns 0 exit status

[Dave Rutherford]

On Mon, May 24, 2010 at 08:32, Greg Wooledge wool...@eeg.ccf.org wrote:
 On Mon, May 24, 2010 at 04:25:48AM -0400, Dave Rutherford wrote:
 On Mon, May 24, 2010 at 02:48, Pitt, David david.p...@anz.com wrote:
         status. This is not expected (at least not by me!). Zero exit
  status is returned with
         any list of commands, e.g. /bin/ls  :.

 That one would, since the second command is 'true'. Replace it
 with 'false' and you should see an exit status of 1.

 You're confused.  In a regular shell, the if the /bin/ls fails, the 
 part never gets executed at all, and the entire thing returns non-zero.

 $ bash -c 'false  :'; echo $?
 1

But it didn't fail because it wasn't run.

Re: undefined reference to `__strtoll'

[Dave Moore]

Hi,
  So how do I compile the 32-bit version of bash?

Should I uninstall the GCC compiler I have and goto 3.4.6 like an earlier
poster?



-dave

On Thu, Feb 11, 2010 at 16:43, Bob Proulx b...@proulx.com wrote:

 Greg Wooledge wrote:
  Dave Moore wrote:
   Machine: hppa2.0w
   OS: hpux11.00
   Compiler: gcc
   ...
   My version of GCC is
gcc -v
   Using built-in specs.
   Target: hppa64-hp-hpux11.00
   Configured with: ../src/configure --enable-languages=c,c++
   --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
   --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
   --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
   --host=hppa64-hp-hpux11.00
   Thread model: single
   gcc version 4.0.0

 Are you trying to compile a 32-bit executable or a 64-bit executable?
 A 32-bit compile should work okay.  But a 64-bit compile /may/ have
 problems.  You may be better off trying to compile a 32-bit
 executable.

  I don't have an HP-UX 11.00 machine to test on, but:

 I don't at this time either.  I used to though.  There is a known
 problem on HP-UX concerning 64-bit compiles.  If the gcc installation
 is trying to use the system header files then this would probably
 trickle through.  The default compilation mode is 32-bit and 32-bit
 builds compile okay.  But a define in inttypes.h is upside-down and
 is broken in 64-bit mode.  From coreutils notes I have the following
 patch to the HP-UX system files (use at your own risk) to fix the
 problem.

  --- /usr/include/inttypes.h.origThu May 30 01:00:00 1996
  +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003
  @@ -489 +489 @@
  -#ifndef __STDC_32_MODE__
  +#ifndef __LP64__

 As I recall in 64-bit mode all of the strtoull et al routines are
 broken without this fix.  It might have eventually gotten fixed
 upstream in some later 11.x release by this late date but I don't
 know.  But the problem as reported seems like it may be related.

 Bob

Re: undefined reference to `__strtoll'

[Dave Moore]

How do I configure the linker to use the system linker instead of gnu LD?

I really appreciate the replies!

-dave

On Thu, Feb 11, 2010 at 15:49, Greg Wooledge wool...@eeg.ccf.org wrote:

 On Thu, Feb 11, 2010 at 12:58:46PM -0500, Dave Moore wrote:
  Machine: hppa2.0w
  OS: hpux11.00
  Compiler: gcc

  Bash Version: 4.1
  Patch Level: 0

 I don't have an HP-UX 11.00 machine to test on, but:

  I'm having trouble compiling bash on HP-UX 4.1.  I can't figure out how
 to
  work around it.  Basically, the version of HP-UX I'm running on doesn't
 have
  strtoll.

 It's not supposed to, as far as I'm aware.  __strtoll is an internal
 libc thing.

 bash-3.2# uname -sr
 HP-UX B.11.11
 bash-3.2# cd /usr/include
 bash-3.2# find . -name '*.h' -exec grep strtoll /dev/null {} +
 ./inttypes.h:extern intmax_t __strtoll (const char *, char**, int);
 ./inttypes.h:extern intmax_t __strtoll ();
 ./inttypes.h:#define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)

 There's no man page for strtoll on HP-UX 11.11 either.

  So when I'm building, I see these errors:

  gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
  -L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o
  y.tab.o general.o make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o
  variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o
  hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o
  version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o
  bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o
  redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o  -lbuiltins -lglob -lsh
  -lreadline -lhistory -lcurses -ltilde -lmalloc -lintl   -ldl
  collect2: ld terminated with signal 11 [Segmentation fault], core dumped

 If your linker is dumping core, you've got a problem with something more
 fundamental than bash.

  general.o(.text+0x334): In function `legal_number':
  /home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to
 `__strtoll'
  braces.o(.text+0xae4): In function `brace_expand':
  /home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to
 `__strtoll'
  ./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax':
  ./printf.def:998: undefined reference to `__strtoll'
  make: *** [bash] Error 1

 This also points to a problem with your toolchain.  Broken header files,
 broken linker, who knows

  My version of GCC is
   gcc -v
  Using built-in specs.
  Target: hppa64-hp-hpux11.00
  Configured with: ../src/configure --enable-languages=c,c++
  --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
  --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
  --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
  --host=hppa64-hp-hpux11.00
  Thread model: single
  gcc version 4.0.0

 I'm using:

 bash-3.2# gcc -v
 Reading specs from /usr/local/lib/gcc/hppa1.1-hp-hpux11.11/3.4.6/specs
 Configured with: ../gcc-3.4.6/configure --with-gnu-as
 --with-as=/usr/local/bin/as
 Thread model: single
 gcc version 3.4.6

 (Yeah, I know, an hppa1.1 machine...!  That was not easy to get gcc
 bootstrapped onto.)

 I don't know if there's a specific problem with gcc 4.0.0 on HP-UX 11.00.
 That's an awful lot of zeros, though.  Things with dot zero on the end
 of them tend to scare me a bit.

 I see you're using GNU ld, which shouldn't be required on this platform.
 And also that ld is dumping core.  You might try upgrading your GNU
 binutils if you want to continue using GNU ld (or even just rebuilding
 your current version); or you might try configuring gcc to use the
 system's linker.

 In any case, I'm pretty sure it's not a bash bug that you're running into.

 (If/when you run into a problem with vsnprintf, *that* is a bash bug,
 fixed in one of the 4.1 patches.  You might grab the bash patches before
 your next attempt, after you get your toolchain working.)

Re: undefined reference to `__strtoll'

[Dave Moore]

Bob,
  I didn't read this carefully -- should I try the patch you suggested
before we do anything else?

-dave

On Thu, Feb 11, 2010 at 16:43, Bob Proulx b...@proulx.com wrote:

 Greg Wooledge wrote:
  Dave Moore wrote:
   Machine: hppa2.0w
   OS: hpux11.00
   Compiler: gcc
   ...
   My version of GCC is
gcc -v
   Using built-in specs.
   Target: hppa64-hp-hpux11.00
   Configured with: ../src/configure --enable-languages=c,c++
   --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
   --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
   --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
   --host=hppa64-hp-hpux11.00
   Thread model: single
   gcc version 4.0.0

 Are you trying to compile a 32-bit executable or a 64-bit executable?
 A 32-bit compile should work okay.  But a 64-bit compile /may/ have
 problems.  You may be better off trying to compile a 32-bit
 executable.

  I don't have an HP-UX 11.00 machine to test on, but:

 I don't at this time either.  I used to though.  There is a known
 problem on HP-UX concerning 64-bit compiles.  If the gcc installation
 is trying to use the system header files then this would probably
 trickle through.  The default compilation mode is 32-bit and 32-bit
 builds compile okay.  But a define in inttypes.h is upside-down and
 is broken in 64-bit mode.  From coreutils notes I have the following
 patch to the HP-UX system files (use at your own risk) to fix the
 problem.

  --- /usr/include/inttypes.h.origThu May 30 01:00:00 1996
  +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003
  @@ -489 +489 @@
  -#ifndef __STDC_32_MODE__
  +#ifndef __LP64__

 As I recall in 64-bit mode all of the strtoull et al routines are
 broken without this fix.  It might have eventually gotten fixed
 upstream in some later 11.x release by this late date but I don't
 know.  But the problem as reported seems like it may be related.

 Bob

undefined reference to `__strtoll'

[Dave Moore]

Configuration Information [Automatically generated, do not change]:
Machine: hppa2.0w
OS: hpux11.00
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='hppa2.0w'
-DCONF_OSTYPE='
hpux11.00' -DCONF_MACHTYPE='hppa2.0w-hp-hpux11.00' -DCONF_VENDOR='hp'
-DLOCALEDI
R='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H
-DHPUX   -I
.  -I. -I./include -I./lib   -g -O2
uname output: HP-UX halflife B.11.00 U 9000/785 2012264887 unlimited-user
licens
e
Machine Type: hppa2.0w-hp-hpux11.00

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

Description:
I'm having trouble compiling bash on HP-UX 4.1.  I can't figure out how to
work around it.  Basically, the version of HP-UX I'm running on doesn't have
strtoll.  So when I'm building, I see these errors:
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
-L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o
y.tab.o general.o make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o
variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o
hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o
version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o
bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o
redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o  -lbuiltins -lglob -lsh
-lreadline -lhistory -lcurses -ltilde -lmalloc -lintl   -ldl
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
general.o(.text+0x334): In function `legal_number':
/home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to `__strtoll'
braces.o(.text+0xae4): In function `brace_expand':
/home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to `__strtoll'
./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax':
./printf.def:998: undefined reference to `__strtoll'
make: *** [bash] Error 1


My version of GCC is
 gcc -v
Using built-in specs.
Target: hppa64-hp-hpux11.00
Configured with: ../src/configure --enable-languages=c,c++
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
--with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
--host=hppa64-hp-hpux11.00
Thread model: single
gcc version 4.0.0


Any help appreciated,
-dave

Re: bash accepts script with incorrect syntax and goes into infinite loop

[Dave B]

On Friday 09 October 2009, Pierre Gaston wrote:

  Repeat-By:
 printf '%s\n%s\n' foo bar | while read NAME;
 echo NAME=$NAME
 do
 echo blah
 done

 Not sure what is the incorrect syntax, and it seems normal that it goes
 into an infinite loop since echo is always true.

Well, it seems to me (and as stated in the bug report) that a do should 
follow the while read NAME;.

-- 
D.

Re: bash accepts script with incorrect syntax and goes into infinite loop

[Dave B]

On Friday 09 October 2009, Pierre Gaston wrote:

  Well, it seems to me (and as stated in the bug report) that a do should
  follow the while read NAME;.

 the while syntax is like this:
 while list; do list; done
 and the manual says A sequence of one or more newlines may appear in a
 list  instead  of  a semicolon to delimit commands.
 so you can have:

 while command
 command
 do

 (the ; in the definition is probably there to keep the definition on one
 line, you can replace the ; in all the other definitions by a newline like:
 if command
 then

 This also works the same way in the other shells. For me it's not a bug.

Uhm, on a more accurate reading you're probably right. The POSIX syntax for 
while is

while compound-list-1 do
compound-list-2
done

And read NAME; echo NAME=$NAME is a compound-list. So I was deceived by the 
formatting, I think you are right. Thanks for correcting me.

-- 
D.

Re: Real easy questions. Please answer

[Dave B]

On Friday 25 September 2009 05:24:04 eatsubway wrote:
 sry i have a stupid question.

 I have a variable and need to know how many items are in it.

 for example:
 variable=abc xyz foo
 what program can i call to print out 3

 right now im doing this...

 Counter()
 {
   echo $#
 }
 Counter $IDs
 but that just seems stupid

Use an array, so you will even be able to store elements with spaces in them.

-- 
D.

Re: Bug in array populating does not respect quotes

[Dave B]

On Thursday 24 September 2009 16:38:12 David Martin wrote:

 Description:
 When populating an array from a string in a variable does not
 handle quotes.

 Repeat-By:

 ~$ declare -a samplearray
 ~$ samplearray=( x y 'z k')
 ~$ echo ${samplearray[2]}
 z k
 ~$ samplestring=x y 'z k'
 ~$ samplearray=( $samplestring )
 ~$ echo ${samplearray[2]}
 'z

Not a bug. This is expected behavior. To do what you want, use eval:

~$ samplestring=x y 'z k'
~$ eval samplearray=( $samplestring )
~$ echo ${samplearray[2]}
z k

-- 
D.

Re: 'time' redirection, and pipe redirections in general

[Dave B]

On Saturday 25 July 2009, Linda Walsh wrote:

   AFAIK, I'm still screwed if I want to create more than one
 pipe for outputs -- either sending stderr to one pipe and stdout to
 another, OR a way of even doing what tee does, but built into the
 shell, so I could, using the building tee, a file descriptor as an
 output target.

IIUC, This can be accomplished with process substitution:

myprogram 1 (command1) 2 (command2) 3 (command3) etc.etc.

where command1 gets what myprogram writes to fd 1, command2 gets what 
myprogram writes to fd 2, etc.etc.

But maybe I'm not understanding correctly what you're looking for.

-- 
D.

Re: Bash script file naming problem?

[Dave B]

On Saturday 25 July 2009, michael rice wrote:
 Is there a problem with naming a bash script file script? I'm using
 Fedora 11.

script is most likely the name of a command installed on your system (on 
mine, it's /usr/bin/script). Try man script and see.
So if you really want to call your script script, but you have to either 
call it using its path (./bin/script in your example), or make sure that the 
shell finds it before the system command for example by modifying PATH.
To be honest, I would just pick a different name for your script.

-- 
D.

Re: regarding 'time' builtin

[Dave B]

On Friday 17 July 2009, Linda Walsh wrote:

 where does the output from the 'time' command go

 I.e. if I wanted to pipe the output to a prog or file, how would I
 go about doing it?

Please see

http://mywiki.wooledge.org/BashFAQ/032

-- 
D.

Re: Possible Feature Requests (unsource, exchange)

[Dave B]

On Tuesday 07 July 2009, Christopher Roy Bratusek wrote:

 Hi all,

 what I'm currently missing are the following two things (I'm not 100%
 sure if they are not available):

 unsource: the opposite of source (while source is making functions
 publically available, unsource would remove them)

source does not make any function available. It just reads and executes the 
contents of the sourced file in the current context. If that file happens to 
contain functions, those functions will be defined and available (not to 
children though, unless they're exported), but it's just a side effect. 
To remove a function, you just unset it:

$ foo() { echo function foo; }
$ foo
function foo
$ unset foo
$ foo
bash: foo: command not found

 exchange: exchanges the value of two variables (x=2 y=a; exchange x y;
 x=a y=2 -- need to be exported, so $1 $2 inside a function/script don't
 help that much)

The traditional way to exchange values between two variable is to use a 
temporary variable:

$ x=a
$ y=2
$ tmp=$x
$ x=$y
$ y=$tmp
$ echo now x is $x, y is $y
now x is 2, y is a

It's not clear to me what you mean by $1 $2 inside a function/script don't 
help.

 echo no-expand: if you do echo $@ ($@ is $x $y for example) echo will
 print the values of $x $y instead of simply $x and $y is there a way to
 achieve this?

Sure, just quote it (and not only here, btw):

$ foo() { echo $@; }
$ foo '$x' '$y'
$x $y


-- 
D.

Re: Creating directories with sticky bit set

[Dave Rutherford]

On Fri, Mar 13, 2009 at 9:30 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
 This still doesn't address the original poster's concerns if, for
 example, a web browser creates a new ~/.browserconf directory the first
 time it's invoked.  But nothing bash can do will solve that.

True, but what about a wrapper?

--- sticky.c
#include dlfcn.h
#include sys/stat.h
#include sys/types.h

int mkdir (const char *path, mode_t mode)
{
typedef int (*FP_mkdir)(const char *, mode_t);
FP_mkdir org_mkdir = dlsym(((void *) -1l), mkdir);
return org_mkdir(path, mode | S_ISVTX);
}
--- building
$ gcc -fPIC -c -Wall sticky.c -o sticky.o
$ gcc -shared sticky.o -ldl -lstdc++ -o sticky.so
--- running
$ export LD_PRELOAD=$PWD/sticky.so:$LD_PRELOAD
--- for long-term use, add to bash startup files

How portable this is I don't know, but I tested it briefly and it
seems okay; YMMV.

Dave

Re: Howto set a Readline variable (not in the init file!)?

[Dave B]

Andi Bachmann wrote:

 Hello
 
 I'm looking for a way to set a Readline variable, but without editing
 the init (~/.inputrc or /etc/inputrc) file.
 
 E.g., I'd like to have
 
set show-all-if-ambiguous on
 
 The thing is that I have to login to some remote server with a login 
 that I share with other users and I don't want to impose my settings by
 saving my options in a file.
 
 I tried
 
   bind set show-all-if-ambiguous on
 
 but this leads to a corrupted readline behaviour: I can't type anymore 's'.
 
 Reading the manual 
 (http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins) it 
 says explicitly (for the Builtin command 'bind'):
 
Display current Readline (see Command Line Editing) key and
 function bindings, bind a key sequence to a Readline function or
 macro, or set a Readline variable.

According to the man, you should pass the readline binding or variable as a
single argument to bind (or at least that's what the example shown seems to
imply), so:

bind 'set show-all-if-ambiguous on'

The above line seems to do the trick for me.

-- 
D.

Re: $(grep anycommand anyfile) fail

[Dave B]

BlackEnvil wrote:

 Description: using ` ` or $() with command that use dirnames with spaces
 fail.
 
 there are diferent dirnames with this problem, and different situations that
 cause these errors, not only with ls and not only with grep.
 
 bye
 
 
 Repeat-By:
 
 [blacken...@space_star ~]$ cd $HOME; mkdir hello\ -world/; touch test; echo
 ls hello\ -world/  test; $(grep ls test);
 ls: invalid line width: orld/
 [blacken...@space_star ~]$

There are actually two problems here.
After the command substitution, the shell does word splitting, and the
command it sees is this (spaced for readability):

ls   hello\   -world
 ^^   ^^
  arg1  arg2

The -world part is interpreted as the option -w to ls, and orld as the
argument to that option, which is an invalid line width. To fix that, use --
to mark the end of options. But even if you do that, you would still get an
error because ls would see two filenames: hello\ and -world, neither of
which exists.

 [blacken...@space_star ~]$ cd $HOME; mkdir hello-\ world/; touch test; echo
 ls hello-\ world/  test; $(grep ls test);
 ls: cannot access hello-\: No such file or directory
 world/:
 [blacken...@space_star ~]$

Same as above: the shell does word splitting on the result of command
substitution, and what it sees is the command (spaced for readability)

ls   hello-\   world
 ^^^   ^
  arg1  arg2

since those files or directory do not exist, ls correctly produces an error.

In both cases what you're seeing is not a bug, but just expected behavior.

-- 
D.

Re: Formating variable with caracter and date.

[Dave B]

Dolphin06 wrote:

 Hello all,
 
 I would like to give a variable a value which have a format like this one:
 3 letters-date-digit
 date should be yymmdd.  Date of the day by default.
 How would i do this, i know the date command is date +%y-%m-%d, but i dont
 know the syntax for mixing letters date and digit into one variable.
 Also i would like to give the user a chance to change this default value, by
 letting him enter one, so i would like to know how can i check if the
 entered value is in the correct format.

First of all, this list if for reporting bash bugs, not for general help
requests. For that purpose, there are other, more appropriate, places, like
for example the Internet newsgroup comp.unix.shell.

Then, regarding your request:

To assign that string to the variable, assuming 3 letters is ABC, and
digit is 5 (replace with your own values), you can do this:

var=ABC-$(date +%y%m%d)-5

The part about checking depends on what you want to check exactly, which
isn't clear from your description.

-- 
D.

Re: Maximum limit of pipes in a single command ?

[Dave B]

Keshetti Mahesh wrote:

 Hi all,
 
 Can anyone tell me what is the maximum limit of number of pipes
 that can be opened through a single command ?
 
 e.g; # cmnd ||| .|

For what is worth, on my system (bash 3.2.33(1)-release) I can have 3332
pipes before bash gives an error. I used this command:

(printf 'echo a';for i in `seq 1 3332`;do printf '|cat';done;echo) | bash

If I replace 3332 with , bash gives

bash: line 1: syntax error near unexpected token `|'

Curiously, with this command

(printf 'echo a';for i in `seq 1 3330`;do printf '|(read a;echo $a)';
done;echo) | bash

the limit is 3330.

Ulimit tells me that the maximum number of user processes is 16381, so it
seems unrelated to that.

Why do you want to know?

-- 
D.

Re: Equivalent of ksh, zsh {N}[WORD] ?

[Dave B]

Pierre Gaston wrote:

   On Tue, Aug 26, 2008 at 5:41 AM, R. Bernstein [EMAIL PROTECTED] wrote:
Both zsh and ksh have a way to open a file or duplicate a file
descriptor and let the interpreter pick the descriptor saving the
newly-allocated file descriptor number in a variable. In particular:
   
  exec {fd}0
 Perhaps you are thinking of the variation without braces?

 
 well, I was thinking of the normal redirection syntax:
 exec 30
 
 I doubt '{fd}0'  is meaningfull anywhere.in ksh {fd} tries to
 run the command {fd} like in bash
 in zsh it tries to run the command fd
 What are you talking about???

I think he refers to the fact that, with ksh, you can do for instance

$ exec {fd}0
$ echo $fd
10
$ exec {fd1}0
$ echo $fd1
11

I didn't try on zsh, but with bash you get:

$ exec {fd}0
-bash: exec: {fd}: not found

-- 
D.

Re: Equivalent of ksh, zsh {N}[WORD] ?

[Dave B]

Pierre Gaston wrote:

 I think he refers to the fact that, with ksh, you can do for instance

 $ exec {fd}0
 $ echo $fd
 10
 $ exec {fd1}0
 $ echo $fd1
 11

 I didn't try on zsh, but with bash you get:

 $ exec {fd}0
 -bash: exec: {fd}: not found

 ah sorry I didn't know this syntax
 
 on which ksh version does this work?

I tried that on a RHEL 5 system with

$ ksh --version
  version sh (ATT Labs Research) 1993-12-28 r

Actually, I just tried zsh, and the version installed on that system (which
looks pretty old) does not support the exec {fd}0 either.

$ zsh --version
zsh 4.2.6 (i686-redhat-linux-gnu)

-- 
D.

Re: 'read' primitive

[Dave B]

Bob Proulx wrote:

 To get the entire line verbatim you would need to use the $REPLY
 variable. 

Or also use

IFS= read -r foo  bar

-- 
D.

Re: How to create parameterized aliases in bashrc

[Dave B]

Aman Jain wrote:

 Hi
 
  I would like to create an alias to show Nth line of a file.
 
  I  tried something like
  alias shline='head -$1 $2 | tail -1'  #$1 is the line number and $2
 is the filename
# Usage should be :
 $shline 5 file.txt
 
 But it isn't working..

You can't pass parameters to aliases.

 Can anyone suggest a better alternative

Use a function.

shline() { head -n $1 $2 | tail -n 1; }

-- 
D.

Re: Regular expression match operation with character classes fails in bash 3.2

[Dave B]

John E. Wulff wrote:

 I have just updated from openSUSE 10.2 to openSUSE 11.0 Linux. My 
 backup shell script
 is now broken. I tracked the problen down to the latest version of 
 bash.
 
 The relatively new binary operator =~ does not match a regular 
 expression which contains a
 character class in square brackets: eg. $xp =~ [0-9]10
 
 The behaviour is the same on a 32 bit machine with openSUSE 11.0 and
 GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu)
 
 All three script lines below match correctly on SuSE Linux 9.3 with
 GNU bash, version 3.00.16(1)-release (i586-suse-linux)
 
 Unfortunately I no longer have access to the bash version which worked
 correctly with openSUSE 10.2
 
 My observation is the fault was introduced fairly recently.
 
 Repeat-By:
 The following very simple regular expression matches:
 xp=310; if [[ $xp =~ 310 ]]; then echo $xp matched; else echo $xp 
 not matched; fi
 
 This does not match in Bash Version 3.2
 xp=310; if [[ $xp =~ [0-9]10 ]]; then echo $xp matched; else echo 
 $xp not matched; fi
 
 This does not match either (more like the line in my broken shell 
 script)
 xp=310; if [[ $xp =~ [0-9][0-9]* ]]; then echo $xp matched; else 
 echo $xp not matched; fi

That has been discussed some days ago, it's the expected behavior. See

http://lists.gnu.org/archive/html/bug-bash/2008-06/msg00083.html

-- 
D.

Re: Strange return codes of continue

[Dave B]

Roman Rakus wrote:

 This is realy strange. I have two examples
 First:
 
 while [ 1 ]; do
   while [ 1 ]; do
 continue 0
   done
 done
 echo $?
 
 
 Second:
 
 while [ 1 ]; do
   while [ 1 ]; do
 continue 0
   done
   echo $?
 done
 echo $?
 
 In first case I have echoed 1. And I am expecting the same result in 
 second case, but I get 0. Can anyone help me and say where is the 
 difference?

continue [n]
   Resume the next iteration of the enclosing for, while, until, or
   select loop.  If n is specified, resume at the nth  enclosing loop.
   n must be = 1.  If n is greater than the number of enclosing loops,
   the last enclosing loop (the ‘‘top-level’’ loop) is resumed. The
   return value is 0 unless the shell is not executing a loop when
   continue is executed.

-- 
D.

Re: [[ ... =~ ... ]] is broken when RHS is quoted

[Dave B]

Alexis Huxley wrote:

 Description:
   [[ ... =~ ... ]] is broken when RHS is quoted

AFAICT that seems to have changed from 3.2alpha. According to the changelog,
from version 3.2alpha, Quoting the string argument to the [[ command's  =~
operator now forces string matching, as with the other pattern-matching
operators.

$ bash -c '[[ ^apple =~ ^apple ]]; declare -p BASH_REMATCH'
declare -ar BASH_REMATCH='()'
$ bash -c '[[ ^apple =~ ^apple ]]; declare -p BASH_REMATCH'
declare -ar BASH_REMATCH='([0]=^apple)'

Spaces (and possibly other special chars) in the RHS should be escaped:

$ bash -c '[[ apple banana =~ ^apple\ banana ]]; declare -p BASH_REMATCH'
declare -ar BASH_REMATCH='([0]=apple banana)'
$ bash -c '[[ apple banana =~ ^(apple)\ (banana) ]]; declare -p BASH_REMATCH'
declare -ar BASH_REMATCH='([0]=apple banana [1]=apple [2]=banana)'

$ bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

-- 
D.

Re: [[ ... =~ ... ]] is broken when RHS is quoted

[Dave B]

Alexis Huxley wrote:

 Quote removal means that, as usual, quotes do not form part of the
 arguments, they merely serve to delimit the arguments, I take it.
 Words between [[ and ]] ... quote removal performed means on *all*
 words between [[ and ]] I take it. Hmm ...  No, that can't be right
 otherwise
 
   bash -c '[[ apple =~ (apple) ]]; echo ${BASH_REMATCH[1]}'
 
 would say apple. Hmmm ... while the CHANGES file indicates that I
 was wrong that bash is broken, I would say that bash is broken
 *w.r.t. the behaviour documented in its man page*. What do you think?

But bash *does* do quote removal, if you supply quoted arguments. If you do

bash -c '[[ apple =~ (apple) ]]; echo ${BASH_REMATCH[1]}'

then bash does quote removal and sees

apple =~ (apple)

Then, since the RHS was quoted, it performs string matching instead of re
matching. But before that it did do quote removal nonetheless.

-- 
D.

Re: unexpected behavior of 'read' builtin

[Dave B]

On Saturday 24 May 2008 02:44, Juliano F. Ravasi wrote:

 Description:
 
 I got bitten by two unexpected (and undocumented) behaviors of
 the 'read' builtin.
 
 The first one is that it doesn't seem to handle word separators
 equally, making distinction when spaces and non-space
 separators are used to separate words.

The man page introduces the concept of IFS whitespace, which seems to include
space and tab characters. 

If IFS has a value  other than the default, then sequences of the whitespace
characters space and tab are ignored at the beginning and end of the word, as
long as the whitespace character is in the value of IFS (an IFS whitespace
character). Any character in IFS that is not IFS whitespace, along with any
adjacent IFS whitespace characters, delimits a field.  A sequence of IFS
whitespace characters is also treated as a delimiter.

So, if I read that correctly (which might not be true of course), when you
assign $'\t' (an IFS whitespace character) to IFS, it seems you fall into the
case where a sequence of IFS whitespace characters is also treated as a
delimiter.

 The second one is that it chops leading and trailing whitespace
 when you provide one variable for assignment, and not when you
 use the default $REPLY.

This /seems/ to be documented. From the man page, section about read:

If no names are supplied, the line read is assigned to the variable REPLY.

So, I guess the line read here really means the whole line, including
leading/trailing spaces.

On the other hand, when even a single name is supplied, word splitting is
performed, so the removal of blanks is expected as the result of that.

-- 
D.

Missing .bash_history Entries

[Dave Jarvis]

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='l$
uname output: Linux jaguar 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 200$
Machine Type: x86_64-pc-linux-gnu

Bash Version: 3.2
Patch Level: 33
Release Status: release

Description:
It is possible to execute commands from the command-line
without them appearing in the .bash_history file. This is a slight
nuisance as any command that is accidentally preceded with a space
will not appear when cycling through commands using the arrow keys.

Repeat-By:
   Precede the command to execute with a single space.

Fix:
   Don't type in a space by accident. ;-)

Re: finding the index at which two strings differ

[Dave B]

On Tuesday 6 May 2008 22:33, Dave B wrote:

 while [ $i -le $((${#a}-1)) ]  [ $i -le $((${#b}-1)) ]; do

while [ $i -lt ${#a} ]  [ $i -lt ${#b} ]; do

-- 
D.

Re: Bash messes up spaces in command line agruments.

[Dave B]

On Tuesday 6 May 2008 16:20, Herrmann, Justin wrote:

 Description: When I try to pass strings inside double or single quotes
 as command line arguments to my Bash script, leading spaces, trailing
 spaces, and multiple grouped embedded spaces are removed from the
 string.  This also prevents me from passing in only a space or spaces as
 arguments to my script.
 
 Repeat-By: Save this script as 'startup':
 
 #!/bin/bash
 echo $#
 for ((index = 0; index = $#; index++))
 do
 echo $index |$(eval echo \${$index})|
 done
 exit 0
 
 then type: ./startup ' some   words  '
 
 the script will print out:
 1
 0 |./startup|
 1 |some words|

This is what I get:

$ ./startup ' some   words  '
1
0 |./startup|
1 |    some       words          |
# ' some   words  '

Note that a space is missing. Try using the simpler indirection notation:

$ cat startup
#!/bin/bash
echo $#
for ((index = 0; index = $#; index++)); do
echo $index |${!index}|# Try using this
echo $index |$(eval echo \${$index})|
done
exit 0

$ ./startup ' some   words  '
1
0 |./startup|
0 |./startup|
1 |some   words  |
1 | some   words  |
# ' some   words  '

I'm not sure about why, using your method, only a single space is lost
(instead of all leading, trailing and all but one intra-words).

I'm using 

$ bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

-- 
D.

Re: Bash messes up spaces in command line agruments.

[Dave B]

On Wednesday 7 May 2008 14:54, Dave B wrote:

 $ ./startup ' some   words  '
 1
 0 |./startup|
 0 |./startup|
 1 |some   words  |
 1 | some   words  |
 # ' some   words  '

This should have been

$ ./startup ' some   words  '
1
0 |./startup|
0 |./startup|
1 | some   words  |
1 |some   words  |
# ' some   words  '

ie, ${!index} works fine, while eval loses a space.

-- 
D.

Re: at which byte do two strings differ

[Dave B]

On Tuesday 6 May 2008 07:53, Nathan Coulter wrote:

 Looking for a simple ways to output the byte at which two strings differ. 
 Here is one:
 
 cmp (echo hello) (echo help) | cut -d' ' -f5 | tr -d ,
 
 Any other suggestions?

I can't see how this pertains to gnu.bash.bug, however try this:

echo 'hello help' | sed 's/\([^ ]*\)[^ ]* \1.*/\1/' | wc -m

(this exploits the fact that a newline is appended at the end, so wc sees an
additional character, and gives the expected result).

If the strings can have spaces in them, then use a different separator.

-- 
D.

Re: finding the index at which two strings differ

[Dave B]

On Tuesday 6 May 2008 21:29, Bob Proulx wrote:

 I can't think of any way to do this natively in bash

Well, there's a loop solution, but it's a bit awkward:

a=help; b=hello; i=0
while [ $i -le $((${#a}-1)) ]  [ $i -le $((${#b}-1)) ]; do
  if [ ${a:${i}:1} = ${b:${i}:1} ]; then 
i=$((i+1))
  else 
break
  fi
done
echo $((i+1))

-- 
D.

Re: for ... in ... do ignores escape characters

[Dave Rutherford]

On Thu, Apr 17, 2008 at 4:21 PM, luiscolorado [EMAIL PROTECTED] wrote:
  Hello, everybody... I'm suffering a huge problem with the for command
  because it wants to parse a variable ignoring escape characters.

  For example, as you know, if I do something like this in bash:

  for i in sony apple hewlett packard
  do
  echo $i
  done

  It will echo the following:

  sony
  apple
  hewlett packard

  However, I have a program that generates a list of files (let's say like the
  previous one) that I want to use. This is what I get when some file names
  have spaces:

  for i in `my-program`
  do
  echo $i
  done

  It echoes the following:

  sony
  apple
  hewlett
  packard


  Did you notice how it broke hewlett packard in two separate strings? That
  is, it uses the spaces to parse the file names!

Quotes or escapes in the output of the `` are input to the shell rather
than shell syntax, so won't be interpreted.  You just need to quote more.

$ foo () { echo sony; echo apple; echo hewlett packard; }

Now note the difference between:

$ for w in `foo`; do echo $w; done
sony apple hewlett packard
   and
$ for w in `foo`; do echo $w; done
sony
apple
hewlett
packard
   and
$ for w in `foo`; do echo $w; done
sony
apple
hewlett packard

Why the first one does that I'm not sure, but it's the last one you want.

Dave

Re: converting an array into a single variable

[Dave Rutherford]

On Wed, Feb 20, 2008 at 2:42 PM, Natan Shar [EMAIL PROTECTED] wrote:
  I can do this with a few id numbers using php, but I need to do this with
  thousands of id numbers on a daily basis using a cron job

  I can successully build an array of the filenames using:
  declare -a imagelist='ls www/images/124534_*.JPG';

  But then I am stuck with the problem of srtipping the 'www/images/' off of
  each array element. I am trying:
   for file in [EMAIL PROTECTED]
   do
   declare newfile=echo $file | sed 's/www\/images\///g'
   echo $newfile
   done;

More complicated than it needs to be.

ITEM=124534
imagelist=`cd www/images; echo $ITEM_*.JPG`
if [ $imagelist = $ITEM_*.JPG ]; then imagelist=; fi
imagelist=${imagelist// /,}

Nothing but builtins.

Dave

Re: Comparison failure

[Dave Rutherford]

On Jan 10, 2008 8:13 AM, Frans de Boer [EMAIL PROTECTED] wrote:
 Following is a function which fails constantly.
[...]
   if [[ $i != -1  $i  $((iPriTblCnt-1)) ]]; then
 echo $((i+1));
   else
 echo -1
   fi

Now, [[ isn't very well documented, so I tend not to use it,
but notice how  behaves here. It looks like it's doing a string
comparison.  Try -lt to get a numeric less-than.

 -- Example trace 1 -
[...]
 ++ [[ 5  54 ]]
 ++ echo 6
[...]
 ++ [[ 6  54 ]]
 ++ echo -1
[...]
 - Example trace 2 -
[...]
 ++ [[ 1  109 ]]
 ++ echo 2
[...]
 ++ [[ 2  109 ]]
 ++ echo -1

Regards,
   Dave

Re: question and/or enhancement request

[Dave Rutherford]

On 7/29/07, Erick Wodarz [EMAIL PROTECTED] wrote:
   I think the following is hard (or impossible?) using bash.  I want to
 create a shell script that will ...

This may be possible, depending on exactly what you need,
but you'd probably be better off trying `expect'.

#!/bin/bash

mknod pipe_to_bash p
mknod pipe_to_prog p

# 1.  Execute a program asynchronously, and return it's PID.

# awk program to multiply by 2, output in bash commands
awk '{ print echo, 2 * $1 ;}'  pipe_to_prog  pipe_to_bash 
childpid=$!
echo awk is $childpid, this bash is $$

# 2.  Have the program read stdin from the shell's current stdout

# (if you write instead
#  exec 91  pipe_to_bash  pipe_to_prog,
#  both programs will block)
exec 91  pipe_to_prog  pipe_to_bash

# give awk some input
echo 5
echo 6
echo 7

exec 9# closes pipe_to_prog (reconnecting original stdout)
# to trigger awk to read input

# 3.  Have the program read write stdout to the shell's current stdin
# (You meant not to say read, right?)

# read the commands output by awk from stdin
eval `while read w; do echo $w; done`
# (. - would be better here... if it worked.
#  Also tried . /dev/stdin without luck.)

rm pipe_to_bash pipe_to_prog

# Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Subnet address

[Dave Rutherford]

On 7/21/07, Archimerged Ark Submedes [EMAIL PROTECTED] wrote:

On 7/20/07, Mike Frysinger [EMAIL PROTECTED] did not read the question.


Neither did you.  ;-)  Asked for was a solution using ifconfig and bash;
you added grep and tr.  Yes, that's entirely reasonable on your part,
but it's not necessary.


The answer is:

 /sbin/ifconfig eth0 |
grep 'inet addr' | tr .: '  ' |
 (read inet addr a b c d Bcast e f g h Mask i j k l;
 echo $(($a  $i)).$(($b  $j )).$(( $c  $k )).$(( $d  $l )) )


Here's an ugly way to do it:

NETADDR=`/sbin/ifconfig |
while read w d z z; do
if [ $w = inet ]; then
d=${d#addr:}; z=${z#Mask:};
a=${d%%.*}; w=${z%%.*}; d=${d#*.}; z=${z#*.};
b=${d%%.*}; x=${z%%.*}; d=${d#*.}; z=${z#*.};
c=${d%%.*}; y=${z%%.*}; d=${d#*.}; z=${z#*.};
echo $((aw)).$((bx)).$((cy)).$((dz));
break;
fi;
done`

And here's a better way, inspired by your use of 'tr':

NETADDR=`/sbin/ifconfig |
while read w x y y; do
if [ $w = inet ]; then
set -- ${x//./ }; a=${1#addr:}; b=$2; c=$3; d=$4;
set -- ${y//./ }; w=${1#Mask:}; x=$2; y=$3; z=$4;
echo $((aw)).$((bx)).$((cy)).$((dz));
break;
fi;
done`

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Evaluate expression every time directory changes

[Dave Rutherford]

On 6/28/07, bash_user [EMAIL PROTECTED] wrote:

Lets say I would like to update environment variable based on ${PWD}
should I clobber my prompt generation routine or there is a better way.


Something like this?

PROMPT_COMMAND='eval NEWPWD=\$PWD'

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to detect bash?

[Dave Rutherford]

On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote:

Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash?


Well, I don't know if it's clever, but how about:

$ if [ ${SHELL//*/bash} = bash ]; then echo y; fi

But better to use the hash-bang and make SURE the shell is Bash.

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to detect bash?

[Dave Rutherford]

On 10/10/06, mwoehlke [EMAIL PROTECTED] wrote:

Completely non-workable. That only works if the bash I want is in
/bin/bash


Well, no.  It works as long as the last thing in the path
is 'bash'.  It could be /usr/bin/bash, /home/bin/bash,
or yes, /bin/bash.  But why the heck don't you know,
if these systems are under your control?

And why the heck do you think this is is *bug* in *bash*?

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: null command and parameter expansion for Display error if null or unset

[Dave Rutherford]

On 7/31/06, Poor Yorick [EMAIL PROTECTED] wrote:

The following line does not perform the echo command.

: ${FAKEVAR?} || echo hello

This seems inconsistent, since the return status is set to one, not to mention 
that the null command is documented to return a zero exit code.  It would be a 
convenient and concise syntax for acting on unset variables.


Try this and then run your script:

export FAKEVAR=echo This could have been rm -rf $HOME

to see why not to do it this way.

On the other hand, if you already know FAKEVAR is not set,
why are you performing a test?

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: null command and parameter expansion for Display error if null or unset

[Dave Rutherford]

On 7/31/06, Paul Jarc [EMAIL PROTECTED] wrote:

Dave Rutherford [EMAIL PROTECTED] wrote:
 On 7/31/06, Poor Yorick [EMAIL PROTECTED] wrote:
 : ${FAKEVAR?} || echo hello

 Try this and then run your script:

 export FAKEVAR=echo This could have been rm -rf $HOME

That won't do anything.  The contents of $FAKEVAR, if any, are just
passed as arguments to :, which does nothing.


Oh, yes; you're quite right.  I couldn't see the colon in this font
and thought he was evaluating a possibly nonempty variable
as a command, which is apparently a bad idea that no-one had.

Sorry.

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: PATH and $0

[Dave Rutherford]

On 7/11/06, Cai Qian [EMAIL PROTECTED] wrote:

In some Linux, it will print /tmp/script.sh, while in other, it will
print script.sh only. Which is wrong? If both are fine, is there any
better way to make it portable?


Which do you want?  (Both are fine.)  If you want 'script.sh',
use 'basename' or the Bash equivalent, which I think is '${0##*/}'.
The canonical path would be a bit trickier.

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

core/loop vi mode when '.' used to repeat a replace

[dave]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: freebsd4.8
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='freebsd4.8' -DCONF_MACHTYPE='i386-unknown-freebsd4.8' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2  -march=pentiumpro
uname output: FreeBSD base686.home.org 4.8-RELEASE FreeBSD 4.8-RELEASE #14: Thu 
Sep  8 12:45:15 CDT 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/base686  
i386
Machine Type: i386-unknown-freebsd4.8

Bash Version: 3.1
Patch Level: 11
Release Status: release

Description:
I've noticed that if I use ',' to repeat a substitution
in vi-mode, bash either dumps core or goes into a hard
loop.

Repeat-By:
Any command should do, I used this now as I was filling out
this form:

  $ set -o vi
  $ date; date; date
  Fri Mar  3 12:53:06 CST 2006
  Fri Mar  3 12:53:06 CST 2006
  Fri Mar  3 12:53:07 CST 2006

Now, with vi-mode in effect, type 'ESC -' to bring up the
date... command, type 'f e' to move the cursor to the
first 'e', type 'r e' to replace the 'e' with 'e', type ';'
to move the cursor to the second 'e', type '.' to repeat
the previous substitution.

For me, bash goes into a hard loop at this point and I need
to 'kill -9' the process.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash problem with #!, rev 2

[Dave Yost]

Thanks for your learned analysis.
1. I kind of like the way zsh handles it.
2. In any case, I'll use #!/usr/bin/env
   http://Yost.com/computers/compileAndGo
3. I'll change my pages to reflect the change by around noon 15:00 UTC+8.

Thanks again.

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

bash problem with #!

[Dave Yost]

Please see
http://Yost.com/computers/compileAndGo

That page describes a #!/bin/bash script called compileAndGo, which 
is used as the program for a #! script.


In other words, a program starting with

  #!/usr/local/bin/compileAndGo

should invoke /usr/local/bin/compileAndGo, and compileAndGo is a 
program starting with


  #!/bin/bash

Invoking a compileAndGo script works correctly in zsh, but not in 
bash, sh, ksh, csh, or tcsh.


(Is this the first time anyone has used a shell script as a #! program?)

Thanks

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash feature request: pushd -v, popd -v

[Dave Rutherford]

On 7/15/05, Ben Horowitz [EMAIL PROTECTED] wrote:
 I grew to appreciate one feature of tcsh: the ability to use
 the commands pushd -v, and popd -v.

 As you know, when the bash pushd and popd commands are successful,
 they print the directory stack.  In tcsh, one can additionally issue
 the command pushd -v, which is like the bash commands pushd followed
 by dirs -v.  This feature appears not to be available in bash.

   tcsh pushd -v /tmp
   0   /tmp
   1   /

Does this do the trick?

pushd ()
{
local verbose=0;
if [ $1 = -v ]; then
verbose=1;
shift;
fi;
builtin pushd $@;
if [ $verbose -eq 1 ]; then
for w in [EMAIL PROTECTED];
do
echo $w${DIRSTACK[$w]};
done;
fi
}

Barely tested (and with bash 3.0 at that), but it seems to do
what you want.  popd would be very similar, of course.

Dave


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash