[PATCH] fix bashdb script handling of tmp directory
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.
--- 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
Bug: terminal width incorrect if changed in child process
PLATFORM bashver 3.00.16(1)-release hardware: intel 32 bit os: fedora core 4 BUG If the terminal width is changed while a child process of bash is running (e.g. less), bash does not notice the change when it regains control and line wrapping for the commandline works incorrectly. RECREATE make terminal width very narrow (like 10 chars) run bash run less make terminal width wide again exit less type in a long command on the commandline FIX bash should query the terminal size (and possibly other similar info that might have changed) when returning from a child process. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Readline Documentation
Hello all, Sorry in advance if this is poorly formatted; I used plain-text mode in gmail but who knows if that works properly. While hunting down some problems on a terminal, I ran across the option 'prefer-visible-bell'. It took me some time looking into this before finding out it was deprecated in favor of 'bell-style' about 20 years ago, per: https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html. Despite that, it still shows up in stackoverflow answers and reddit threads even from as recently as six months ago: https://www.reddit.com/r/bashonubuntuonwindows/comments/1b55k9f/that_stupid_bell/kt3l0hm/. Could this option be documented in the man page? It would have saved me a bit of wasted time, and it would give me a resource to point to (other than an old mailing list thread) to authoritatively state it's been superseded. Is it non-functional now? If so, is it synonymous with setting bell-style visual? And is setting it off synonymous with bell-style none? Additionally, as discussed in the mail link above, I think the 'convert-meta' and 'input-meta' need slightly more description. For example, is this statement accurate: "The convert-meta variable has no effect if input-meta is off." From the manpage I would think so, but I'm just not confident. I also can't tell conclusively whether the output-meta variable is affected by convert-meta, or vice-versa. Thanks for your time, John Devin
Re: Readline Documentation
Hey Chet, Thanks for getting back so fast. Just a couple points to make. On Thu, Sep 12, 2024 at 4:38 PM Chet Ramey wrote: > > On 9/11/24 3:19 PM, John Devin wrote: > > While hunting down some problems on a terminal, I ran across the > > option 'prefer-visible-bell'. It took me some time looking into this > > before finding out it was deprecated in favor of 'bell-style' about 20 > > years ago, per: > > https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html. > > As the last line in that message says, it was never documented. Readline > didn't really even have documentation until version 2.1 in 1997, well > after bell-style. > > > > > Despite that, it still shows up in stackoverflow answers and reddit > > threads even from as recently as six months ago: > > https://www.reddit.com/r/bashonubuntuonwindows/comments/1b55k9f/that_stupid_bell/kt3l0hm/. > > > > Could this option be documented in the man page? > > As you said, it's been deprecated -- and undocumented -- for over 30 years > (and remains only for backwards compatibility). There's no reason to > document it. > I understand it's been superseded, but I do want to point this out: running `bind -v` in bash 5.2.21 right now still lists 'set prefer-visible-bell on' in its output. I considered that maybe it would only do this in response to being set directly, but neither ~/.bashrc nor /etc/bash.bashrc on my system include it, nor any other file I can find. Unless this has been changed between that version and now, it means bash is currently reporting a variable with no way to discover what it means or what its effects are without changing it and testing. > > It would have saved > > me a bit of wasted time, and it would give me a resource to point to > > (other than an old mailing list thread) to authoritatively state it's > > been superseded. > > It's been superseded. It's not just undocumented; it's not supposed to be > used. But there was no reason to break users' startup files, and that is > still true. > > (Yes, I would have hoped usage would have dried up, but change is hard.) > The fact that its usage continues suggests documenting it as deprecated would be beneficial. Many of the stackoverflow/reddit/etc discussions I found while looking into this included people using both 'bell-style' and 'prefer-visual-bell' simply because they didn't know what one meant, and then keeping both in their config once they found the combination that did what they wanted. Essentially, I think it's being cargo-culted. The fact that `bind -v` still reports it certainly doesn't help. As a comparison, I would like to point out that 'meta-flag' (which `bind -v` also reports) is still documented as a synonym for 'input-meta' even though it appears that replacement also happened around the same time as 'bell-style', ie pre-bash 2.0. > > Additionally, as discussed in the mail link above, I think the > > 'convert-meta' and 'input-meta' need slightly more description. For > > example, is this statement accurate: "The convert-meta variable has no > > effect if input-meta is off." From the manpage I would think so, but > > I'm just not confident. I also can't tell conclusively whether the > > output-meta variable is affected by convert-meta, or vice-versa. > > Those descriptions have undergone fairly significant changes, the result > of this thread: > > https://lists.gnu.org/archive/html/bug-readline/2024-08/msg3.html > Aw, I see. Thanks for the link. - John
Manpage typo
On line 3987 of bash.1 (here: https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1#n3987), `The\fBextglob\fP` is missing a space between 'The' and 'extglob'. I'm not sure how small typos have to be before they're not worth an email, so if this is, let me know. - John Devin
Re: Readline Documentation
On Fri, Sep 13, 2024 at 3:24 PM Chet Ramey wrote: > > > I considered that maybe it > > would only do this in response to being set directly, but neither > > ~/.bashrc nor /etc/bash.bashrc on my system include it, nor any other > > file I can find. Unless this has been changed between that version and > > now, it means bash is currently reporting a variable with no way to > > discover what it means or what its effects are without changing it and > > testing. > > It has no effects in its default state. If you don't change it, nothing > happens. If you change it, you change `bell-style' instead. > Those three sentences are more-or-less what I would be asking be added to the documentation (along with "Don't use this, use bell-style instead"). > > The fact that its usage continues suggests documenting it as > > deprecated would be beneficial. > > Maybe. Or maybe it's just time to remove it once and for all. > I didn't think that would be considered as an option, so if it is then I guess it might render my point moot. Does 'remove it' here mean that it will no longer have any effect? And if so, would it be reported as 'unknown variable name' if set in an .inputrc? Or maybe it won't report 'unknown variable name', but it also won't have any effect? Either way, I suppose `bind -v` won't list it anymore? Out of curiosity, would 'meta-flag' be remaining? > > Many of the stackoverflow/reddit/etc > > discussions I found while looking into this included people using both > > 'bell-style' and 'prefer-visual-bell' simply because they didn't know > > what one meant, and then keeping both in their config once they found > > the combination that did what they wanted. Essentially, I think it's > > being cargo-culted. The fact that `bind -v` still reports it certainly > > doesn't help. > > Did these discussions note that it's not documented? > I think I can answer 'yes' to that, even if I can't quote any one post as saying "This isn't documented in the manpage." These two users (https://superuser.com/a/1620055) seem to have had some trouble, to the point that they had the right answer first and "un-corrected" it (see the edit history) to the wrong one: "I could have swore it used to be different, but so goes my memory!" - user at that link. Again though, kind of moot, if it's being removed so not much to discuss there. - John Devin
