[Bashdb-devel] Re: [PATCH] fix bashdb script handling of tmp directory
I've been meaning to thank Eric Blake for packaging the bash debugger
on cygwin (where others previously had either no interest or gave
up). So thanks!
That said, this bug report isn't relevant to full-fledged bash
debugger, but the older pot-bellied pig debugger which is included in
the bash distribution. In the past that code was a bit lacking,
probably still is and should be discarded (but given past history
probably won't be for a long time). The debugger from
http://bashdb.sourceforge.net in fact does understand "bashdb -V" and
"bashdb -h"
I'm sorry for the confusion of names that both are called bashdb. But
in truth there are probably a couple more bashdb's of historical
importance (unless you're running an old version of bash) which are
out there as well. In the past, I tried calling the project rebash,
and source-code include files have been renamed from bashdb-main.inc
to dbg-main.inc. But alas confusion persists and I don't know how to
reduce it without a lot of work.
Finally, I should note that when submitting patches having them quoted
like this:
> According to [EMAIL PROTECTED] on 9/21/2005 11:53 AM:
...
> --- old-bashdb 2005-09-21 10:26:32.0 -0700
> +++ bashdb 2005-09-21 10:48:12.0 -0700
> @@ -509,11 +509,11 @@
>fi
just makes it harder to apply the patch.
Eric Blake writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [forwarding to bashdb-devel]
>
> According to [EMAIL PROTECTED] on 9/21/2005 11:53 AM:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: i386
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
> > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-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
> > -g -O2
> > uname output: Linux dungeon2 2.6.11-1-k7-smp #1 SMP Mon Jun 20 22:34:51
> > MDT 2005 i686 GNU/Linux
> > Machine Type: i386-pc-linux-gnu
> >
> > Bash Version: 3.0
> > Patch Level: 16
> > Release Status: release
> >
> > Description:
> >Using bashdb on scripts with directory components in their names
> >failes because it tried to create a temporary file in tmp
> >without stripping the directories and it failes becuase the
> >directories do not exist.
> >
> > Fix:
> >Included is a patch that strips the directory names from
> >$_guineapig before creating a temporary file.
> >
> >For good measure it also strips the dirs before outputing the
> >lines in the file. It just makes it look better.
>
> This patch is to bashdb, not bash. Meanwhile, I just noticed that 'bashdb
> - --help' and 'bashdb --version' are not accepted, and that neither 'bashdb
> - -h' nor 'bashdb -V' output a bug-report address.
>
> >
> > --- old-bashdb 2005-09-21 10:26:32.0 -0700
> > +++ bashdb 2005-09-21 10:48:12.0 -0700
> > @@ -509,11 +509,11 @@
> >fi
> >
> >if (( $line < 100 )); then
> > -_msg "$_guineapig:$line $bp $cl${_lines[$line]}"
> > +_msg "${_guineapig/*\//}:$line $bp $cl${_lines[$line]}"
> >elif (( $line < 10 )); then
> > -_msg "$_guineapig:$line $bp $cl${_lines[$line]}"
> > +_msg "${_guineapig/*\//}:$line $bp $cl${_lines[$line]}"
> >elif (( $line > 0 )); then
> > -_msg "$_guineapig:$line $bp $cl${_lines[$line]}"
> > +_msg "${_guineapig/*\//}:$line $bp $cl${_lines[$line]}"
> >fi
> > }
> >
> > @@ -564,7 +564,7 @@
> > let _i=1
> >
> > # Be careful about quoted newlines
> > -_potbelliedpig=${TMPDIR-/tmp}/$_guineapig.$$
> > +_potbelliedpig=${TMPDIR-/tmp}/${_guineapig/*\//}.$$
> > sed 's,\\$,,' $_guineapig > $_potbelliedpig
> >
> > Thanks,
> > Devin Bayer
> >
> >
> >
> > ___
> > Bug-bash mailing list
> > Bug-bash@gnu.org
> > http://lists.gnu.org/mailman/listinfo/bug-bash
> >
>
> - --
> Life is short - so eat dessert first!
>
> Eric Blake [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDM0fy84KuGfSFAYARAthcAJ4kdxLnzgpveXaU1UJLsGpml+Tj4wCgpm4E
> cRszTqsUUBzY5Q0FcstJ0SY=
> =qIEM
> -END PGP SIGNATURE-
>
>
> ---
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> ___
> Bashdb-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>
Equivalent of ksh, zsh {N}<[WORD] ?
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
will duplicate stdin and save the newly allocated file-descriptor
number to fd. Also:
exec {fd}
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston writes:
> 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
> >
> > will duplicate stdin and save the newly allocated file-descriptor
> > number to fd. Also:
> >
> > exec {fd} >
> > opens filename with a new file descriptor and saves the number
> > allocated in fd. Short of going outside of the language and using
> > lsof, /proc, or the processes table, I haven't been able to figure out
> > how to do the corresponding thing in bash. Is there a way?
> >
> > If not, it would be great if a future version had this extension that
> > zsh and ksh both seem to have.
> >
> > Thanks!
>
> This is a standard behaviour and you can do this in pretty much any
> shell out there, including bash.
Really? It doesn't seem to be documented in bashref. And when I tried just
a moment ago:
$ {fd}<&0
{fd}<&0
bash: {fd}: command not found
$ bash --version
bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Perhaps you are thinking of the variation without braces?
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston writes:
> On Tue, Aug 26, 2008 at 4:49 PM, R. Bernstein <[EMAIL PROTECTED]> wrote:
> > Pierre Gaston writes:
> > > 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
> > > >
> > > > will duplicate stdin and save the newly allocated file-descriptor
> > > > number to fd. Also:
> > > >
> > > > exec {fd} > > >
> > > > opens filename with a new file descriptor and saves the number
> > > > allocated in fd. Short of going outside of the language and using
> > > > lsof, /proc, or the processes table, I haven't been able to figure out
> > > > how to do the corresponding thing in bash. Is there a way?
> > > >
> > > > If not, it would be great if a future version had this extension that
> > > > zsh and ksh both seem to have.
> > > >
> > > > Thanks!
> > >
> > > This is a standard behaviour and you can do this in pretty much any
> > > shell out there, including bash.
> >
> > Really? It doesn't seem to be documented in bashref. And when I tried just
> > a moment ago:
> >
> > $ {fd}<&0
> > {fd}<&0
> > bash: {fd}: command not found
> > $ bash --version
> > bash --version
> > GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
> >
> > Perhaps you are thinking of the variation without braces?
> >
>
> well, I was thinking of the normal redirection syntax:
> exec 3<&0
>
> 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 suppose this is new enough stuff that you would need recent ksh
or zsh version to see it. From a recent ksh 93t manual:
If one of the above, other than >&- and the ># and ># forms, is
preceded by ing space, then a file descriptor number > 10 will
be selected by the shell and stored in the variable varname.
If >&- or the any of the ># and ># forms is preceded by
{varname} the value of varname defines the file descriptor to
close or position. For example:
... 2>&1
means file descriptor 2 is to be opened for writing as a duplicate of
file descriptor 1 and
exec {n}
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Chet Ramey writes:
> R. Bernstein 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
> >
> > will duplicate stdin and save the newly allocated file-descriptor
> > number to fd. Also:
> >
> >exec {fd} >
> > opens filename with a new file descriptor and saves the number
> > allocated in fd. Short of going outside of the language and using
> > lsof, /proc, or the processes table, I haven't been able to figure out
> > how to do the corresponding thing in bash. Is there a way?
>
> There's no current way to do this -- it's a new feature. It's on the
> list of possible future enhancements, but I haven't yet seen a
> compelling enough case as to its value to make it a priority.
>
> Chet
Ok. Let me then try to make a case for it. Basically the application
is stack-line input reading.
The bash debugger and has command (really a gdb command) "source FILE"
which opens FILE for input and starts reading debugger commands from
that. However inside that command file you could have another source
FILE command which reads that command file and when that's finished we
go back to reading the previous file or perhaps stdin.
Right now what bashdb assumes that file descriptors 4 through 9 are
free, but it really has no right to assume that. And in fact, GNU
autoconf configure will use file descriptors in this range. Also using
4-9 we is pretty limited in in file descriptors. This is less of an
issue, but still annoying and arbitrarily restrictive.
Leaving out the initial dup of stdin, here's some code that does this
in ksh93t:
filename='./1.cmd'
typeset -i i=0
typeset -a fd=()
{fd[0]}<$filename
while (( i >= 0 )) ; do
while read cmd file <&${fd[i]}; do
print $i ${fd[i]} $cmd $filename
if [[ $cmd == 'source' ]] ; then
{fd[++i]}<$filename
fi
done
unset fd[i--]
done
Likewise code in zsh which does the same thing:
filename='./1.cmd'
exec {fdi}<$filename
fd+=($fdi)
while (( [EMAIL PROTECTED] > 0 )) ; do
while read cmd filename <&${fdi}; do
print [EMAIL PROTECTED] $cmd $filename
if [[ $cmd == 'source' ]] ; then
exec {fdi}<$filename
fd+=($fdi)
fi
done
fd[-1]=()
(( [EMAIL PROTECTED] <= 0 )) && break
fdi=${fd[-1]}
done
Both of these are in fact right now in the skeletal zshdb and kshdb code
For example: http://github.com/rocky/kshdb/tree/master/lib/processor.sh
(_Dbg_process_commands)
and http://github.com/rocky/kshdb/tree/master/lib/processor.sh
I think it would be a useful fix to bashdb as well.
Thanks.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Chet Ramey writes: > R. Bernstein wrote: > > > Right now what bashdb assumes that file descriptors 4 through 9 are > > free, but it really has no right to assume that. And in fact, GNU > > autoconf configure will use file descriptors in this range. Also using > > 4-9 we is pretty limited in in file descriptors. This is less of an > > issue, but still annoying and arbitrarily restrictive. > > Why do you limit yourself to file descriptors 4-9? Bash doesn't restrict > you to single-digit fds. I know there have been close-on-exec problems > with fds > 10 in the past, but those should be fixed. bashref.texi says this: Redirections using file descriptors greater than 9 should be used with care, as they may conflict with file descriptors the shell uses internally. I'm not sure I what this means. What "care" is supposed to be used? How do I find out what file descriptors bash has used internally, what from a debugger's standpoint the debugged program has opened, and what's free for me to use and how I can register that? Not knowing this, the safest thing here seems to be to avoid file descriptors over 9 altogether. Please feel free to clarify or elaborate on the cited paragraph. Thanks.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Chet Ramey writes:
> > Redirections using file descriptors greater than 9 should be used with
> > care, as they may conflict with file descriptors the shell uses
> > internally.
...
> The sentence is more a caution about the previously-mentioned clexec bugs.
> As a practical matter, you should be able to use fds over 20 without
> problems, but that is not portable across shells.
Okay. I suppose then that sentence should be rewritten in light of the
clexec bug fixes. As is, it can be read as discouragement to using
file descriptors greater than 9.
>
> You should not need to know what fds bash is using, nor what is "free" to
> use -- the idea is that bash will take care of saving and restoring file
> descriptors when it needs to. The requirement to know what file
> descriptors you have open is new and not easily satisfied by the existing
> redirections.
So you've then just given a good reason why the form {n}<[word] is
desirable. Yes, a programmer does not really want to manage file
descriptors but would prefer bash to handle that. But because you
can't currently ask bash to select one and give back some sort of
object that can be used in a read, the only other good alternative is
for the programmer to use something like lsof of look at the process
table to figure out what's in use.
And the standard C libraries also work like {n}<[word] works
also. When you open, the C library selects the descriptor and returns
that.
