Bug#1069978: bash: incorrect value of $BASH for login shells
On 4/28/24 6:18 PM, Gioele Barabucci wrote:
On 28/04/24 22:50, Chet Ramey wrote:
On 4/28/24 3:07 PM, Gioele Barabucci wrote:
$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'
/bin/bash
/usr/bin/bash-static
-bash-static
So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').
Then when you get to setting $BASH, this code gets executed:
if ((login_shell == 1) && RELPATH(shell_name))
{
if (current_user.shell == 0)
get_current_user_info ();
name = savestring (current_user.shell);
}
which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?
The bash manual defines $BASH as follows:
Expands to the full filename used to invoke this instance of bash.
So, either the code or the manual should be changed.
I see why changing such an old behavior for the sake of correctness may not
be worth the risk of breaking somebody's workflow. But at the same time it
is hard to believe that anybody may be relying on "$BASH contains the user
shell set up in /etc/passwd when read from a login shell".
I think the original intent of this code -- it was a very long time ago --
was that a login shell either came from login/getty/xterm or su. If it came
from su, the name in argv[0] was either "-su" (the traditional behavior of
`su -'/`su -l') or the user's login shell. The Linux-specific business of
specifying the shell to use didn't come along until much later. Non-Linux
systems still put "su"/"-su" in argv[0].
In that light, it's easy to see what's happening. You want to change "-su"
to something reasonable, and the user's login shell is what su always uses.
If it's already the login shell, no loss.
I think we can fix this Linux issue by checking for and changing "-su"/"su"
to the login shell and letting other pathnames through.
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1069978: bash: incorrect value of $BASH for login shells
On 4/27/24 6:23 PM, Gioele Barabucci wrote: Package: bash Version: 5.2.21-2 X-Debbugs-CC: bug-b...@gnu.org Hi, bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /usr/bin/bash-static /usr/bin/bash-static $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /bin/bash /usr/bin/bash-static (bash-static is not a link to bash) What does `su' pass to bash in argv[0]? -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069978: bash: incorrect value of $BASH for login shells
On 4/28/24 3:07 PM, Gioele Barabucci wrote:
$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'
/bin/bash
/usr/bin/bash-static
-bash-static
So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').
Then when you get to setting $BASH, this code gets executed:
if ((login_shell == 1) && RELPATH(shell_name))
{
if (current_user.shell == 0)
get_current_user_info ();
name = savestring (current_user.shell);
}
which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#935905: bash: ":?xxx" filename broken on autocomplete
On 4/27/24 5:46 PM, Kerin Millar wrote: On Sat, 27 Apr 2024 23:28:49 +0200 Gioele Barabucci wrote: Control: found -1 5.2.21-2 On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek wrote: the autocompletion is broken on filenames or directories with ":?" at the beginning. # mkdir ':?aa' # rmdir : gives me # rmdir :\:\? which doesn't match the filename; I can finish completion by entering "aa", but then "rm" rejects this name. In bash 5.2.21(1) the filename is now fully completed, but the stray ":" at the beginning is still produced: $ mkdir ':?aa' $ rmdir : $ rmdir :\:\?aa/ In the course of trying this in bash-5.3-alpha, I noticed something else. If ':?aa' is not the only entry in the current working directory, readline behaves as if : is an ambiguous completion. The word being completed is "". -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#935905: bash: ":?xxx" filename broken on autocomplete
On 4/27/24 5:28 PM, Gioele Barabucci wrote: Control: found -1 5.2.21-2 On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek wrote: the autocompletion is broken on filenames or directories with ":?" at the beginning. # mkdir ':?aa' # rmdir : gives me # rmdir :\:\? which doesn't match the filename; I can finish completion by entering "aa", but then "rm" rejects this name. In bash 5.2.21(1) the filename is now fully completed, but the stray ":" at the beginning is still produced: $ mkdir ':?aa' $ rmdir : $ rmdir :\:\?aa/ `:' is one of the characters in the default value of COMP_WORDBREAKS, which is how bash exposes the set of characters readline uses to break words for completion. The word being completed here is "". If you want to complete a filename starting with `:', quote it with a backslash. -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#973620: bash: overflow on integer variables greater than 9223372036854775807
On 4/15/24 7:59 AM, Gioele Barabucci wrote:
Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org
On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote:
Dear Maintainer,
recently while I was running some tests, I ran into this strange overflow:
$ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$i ->
$n";
n+=1; done
0 -> 9223372036854775800
1 -> 9223372036854775801
2 -> 9223372036854775802
3 -> 9223372036854775803
4 -> 9223372036854775804
5 -> 9223372036854775805
6 -> 9223372036854775806
7 -> 9223372036854775807
8 -> -9223372036854775808
9 -> -9223372036854775807
10 -> -9223372036854775806
11 -> -9223372036854775805
12 -> -9223372036854775804
13 -> -9223372036854775803
14 -> -9223372036854775802
The integer handled by bash is obviously very large, but I believe
that in the event of an overflow it would be better to reset the
variable and issue an error flow warning, rather than remain silent.
Hi. Thanks for the report. As documented, bash integer arithmetic doesn't
check for overflow (it never has). Adding such checks is a low-priority
item.
Chet
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#306043: bash executable completion doesn't work if there is a space in the executable path
On 4/5/24 5:21 PM, Gioele Barabucci wrote: Control: found -1 5.2.21-2 Control: tags -1 upstream X-Debbugs-CC: bug-b...@gnu.org On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton wrote: Bash executable completion doesn't work if there is a space in the executable path. This issue is still partially present in current version of Bash. The most basic case has been fixed: $ touch "cmd with spaces" $ chmod +x "cmd with spaces" $ PATH=$PWD:$PATH $ cmd $ cmd\ with\ spaces However there seems to be a linger issue that appears when multiple commands with spaces match a given prefix: Thanks for the report. This will be fixed in the next push to the bash devel branch. Chet -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#972672: bash SIGSEGV related to locale
On 11/4/20 7:16 AM, Thomas Schwinge wrote: >> I suspect that the bug is the "len" argument on the previous line >> n = wcsrtombs(pathname, (const wchar_t **), len, ); >> >> Here "len" is byte length obtained for the original string from >> strlen(). But the call seems to expect the length of the wide character >> version in wpathname which was obtained above with xdupmbstowcs(), and >> so the code should use the return value of that function (in variable >> n) instead of len. Using too long a length makes wcsrtombs() set the >> pointer to NULL when it continues to a zero character. > > So this is different from the change that Chet (CCed) applied to upstream > bash-5.1-rc2, 'lib/glob/glob.c': > <https://git.savannah.gnu.org/cgit/bash.git/diff/lib/glob/glob.c?h=bash-5.1-rc2> > (via <https://bugs.debian.org/972286>). > > I cannot comment on the details, as I'm not at all familiar with these > string APIs. Chet? The prototype for wcsrtombs is (simplified): size_t wcsrtombs(char *dst, wchar_t **src, size_t len, mbstate_t *ps) In the prototype, LEN is the maximum number of bytes to store in DST. In bash, since LEN is set from the number of bytes in the original pathname, and the possibly-modified multibyte character pathname cannot contain more than that number of bytes, LEN is appropriate. -- ``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/
Bug#972286: coreutils: Crash when using globs on a path with non-latin characters
On 10/30/20 1:41 PM, Bernhard Übelacker wrote: > Bash Version: 5.1 > Patch Level: 0 > Release Status: rc1 > > > > Description: > > Dear Maintainer, > I tried to collect some more information for the bug described in [1] > and could reproduce the crash just by repeating the given commands > in a minimal debian testing qemu VM. Backtrace in [2]. > The last bash version where the crash did not manifest was bash_5.0-7. > > In #972672 the last message mentions also wdequote_pathname and > wcsrtombs, therefore I guess this might be related. > > As wcsrtombs[3] is specified to set under certain circumstances *src to > NULL, > I assume in this line [4] wpathname should not get dereferenced, or > at least just after being checked for a non-NULL value. Thanks for the report and the pointer to a fix. Chet -- ``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/
Bug#935115: bash: [regression] passing variable assignments to functions broken in POSIX mode, violating POSIX
On 8/19/19 11:47 AM, Thorsten Glaser wrote:
> Package: bash
> Version: 5.0-4
> Severity: critical
> Justification: breaks unrelated software
>
> The expected output is:
>
> dbc_mysql_createdb: _dbc_nodb(1)= # initially not set / empty
> dbc_mysql_exec_command: _dbc_nodb=yes # MUST be visible inside the function
> inner: 0 or 1 # MAY be exported, does not need to
> dbc_mysql_createdb: _dbc_nodb(2)=[yes]# MAY be visible afterwards,
> optional
> after: 0 or 1 # if visible afterwards MAY be exported
> dbc_mysql_createdb:0
>
> POSIX reference:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
> specifically:
>
> * If the command name is a function that is not a standard utility
>implemented as a function, variable assignments shall affect the
>current execution environment during the execution of the function.
>It is unspecified:
>+ Whether or not the variable assignments persist after the
> completion of the function
>+ Whether or not the variables gain the export attribute during the
> execution of the function
>+ Whether or not export attributes gained as a result of the variable
> assignments persist after the completion of the function (if
> variable assignments persist after the completion of the function)
This behavior hasn't changed substantially since bash-4.4: it still
implements the previous version of the Posix standard, which says that
assignment statements preceding functions are supposed to be treated like
special builtins.
$ cat x15b
# test whether or not temporary environment assignments are exported
# in posix mode
#set -o posix
showfoo()
{
printf %s "foo=${foo-}"
echo -n ' environment foo='
printenv foo || echo
}
unset foo
showfoo
foo=foo showfoo
showfoo
$ ./bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
$ ../bash-5.0-patched/bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
$ ../bash-4.4-patched/bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
(The first test uses the current development version.)
I don't see substantial differences when I interpose another function in
between and call showfoo from that function with a preceding assignment
statement.
There is a problem with bash-5.0 when the variable is declared local in
the interposed function, and I need to fix that, but that's not a posix
issue because posix doesn't have anything to say about local variables.
So thanks for the report, and I'll look at the local variable issue.
--
``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/
Bug#806945: Installation of PDF/PS/DVI and HTML files
On 12/6/15 4:18 PM, Ludovic Courtès wrote: >>> As Mathieu wrote, I am of course fine installing man and Info manuals by >>> default, like GNU packages generally do. >>> >>> The suggestion I make is to not install PDF/PS/DVI and HTML files by >>> default. >> >> Again, only the HTML files are installed by `make install'. The sticking >> point here appears to be installing the HTML files, > > Right, HTML and PDF/PS/DVI. Please read what I wrote. The PDF/PS/dvi files are not installed by any target. >> which you can suppress by running `make install' with htmldir set to >> the empty string. > > I guess that would work, indeed. > >>> This would comply with the GCS and user expectations, and also >>> sidestep the bit-for-bit reproducibility issues that generating those >>> PDF/PS/DVI/HTML files entails. And now we're back to generating the files. >> So the problem is once again the build and not the install? Since the >> build version appears in the version string, and that changes each time >> the binary is rebuilt, bit-by-bit reproducibility is not going to be >> generally possible. > > The broader context is that Debian has a policy of rebootstrapping > packages; that is, even if there’s a ‘make dist’-produced tarball, they > will run ‘autoreconf’ et al. > > In the case of Bash, that entails a rebuild of the HTML and PDF/PS/DVI > files. Well, it involves generating them, since up through bash-4.3, the standard distribution does not include them. Starting with bash-4.4, they'll be in the distribution, so that will not be a problem. (If history is any guide, though, it will be 2-3 years before Debian has cycled to bash-4.4.) I'm going to assume that even running autoreconf doesn't change enough files to cause existing targets to be rebuilt when their source doesn't change (i.e., it's not run with --force). There are two problems discussed at > <https://bugs.debian.org/806945>: > > 1. The man2html copy that Bash provides produces non-deterministic > output; Yes, because of a timestamp. This will not be a problem if the files don't have to be generated. How about this: I will make sure that shipping the generated documentation will not cause files to be regenerated, and that this will work whether the build is done in the source directory or not. > > 2. DVI/PS/PDF generation is not deterministic; this is not a > Bash-specific issue, but the fact that Bash tries to install these > files by default make the issue visible to Debian. This is simply false. You seem to be using generate and install interchangeably. See above for the solution to generating these files with `make all'. > While discussing it with Akira and others, it occurred to me that Bash > shouldn’t be installing HTML/PDF/PS/DVI by default, at least per my > understanding of the GCS and its implementation in Automake, hence my > proposal. So installing the html files is a separate issue, unrelated to the issues raised by the `reproducible builds' folks. -- ``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/
Bug#806945: Installation of PDF/PS/DVI and HTML files
On 12/4/15 4:24 AM, Ludovic Courtès wrote: > Greg Wooledge <wool...@eeg.ccf.org> skribis: > >> On Thu, Dec 03, 2015 at 01:08:13PM +0200, Ludovic Courtès wrote: >>> Given that the GCS suggests installing only the Info version of the >>> manual by default (info "(standards) Standard Targets") >> >>> What do you think? >> >> I think that's a stupid suggestion. The de facto standard for "make" >> followed "make install" on a Unix-like system is to install man pages. >> If there's an info page, I have no objection to installing that as well, >> but to omit the standard man pages by default is ridiculous. > > Agreed; apologies for being unclear. > > As Mathieu wrote, I am of course fine installing man and Info manuals by > default, like GNU packages generally do. > > The suggestion I make is to not install PDF/PS/DVI and HTML files by > default. Again, only the HTML files are installed by `make install'. The sticking point here appears to be installing the HTML files, which you can suppress by running `make install' with htmldir set to the empty string. Is that what you're saying? > This would comply with the GCS and user expectations, and also > sidestep the bit-for-bit reproducibility issues that generating those > PDF/PS/DVI/HTML files entails. So the problem is once again the build and not the install? Since the build version appears in the version string, and that changes each time the binary is rebuilt, bit-by-bit reproducibility is not going to be generally possible. However, if it's the build, if something changes when you run make, it implies that one of the source files changed or that the target did not exist. bash-4.4, unlike bash-4.3, will ship with the generated documentation (look at the bash-4.4-beta distribution, for example). Given that, under what circumstances would the generated documentation need to be rebuilt by this `reproducible builds' effort? -- ``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/
Bug#806945: Fwd: Re: Installation of PDF/PS/DVI and HTML files
--- Begin Message ---
On 12/3/15 6:05 AM, Ludovic Courtès wrote:
> Hello,
>
> Akira of Debian noticed that ‘make all’ rebuilds and install
> PDF/PS/DVI/HTML documentation by default, which prevents default Bash
> builds from being bit-reproducible¹.
This isn't completely accurate, since `make all' doesn't install anything.
So is it the building in the build directory or the installation not
being minimal enough that is the problem?
>
> Given that the GCS suggests installing only the Info version of the
> manual by default (info "(standards) Standard Targets"), what about a
> change along the lines of the patch below?
That's not quite what it says. It suggests that the `install' target
install the info file, but leaves other files up to the discretion of
the package maintainer.
> --- a/doc/Makefile.in
> +++ b/doc/Makefile.in
> @@ -146,9 +146,9 @@ BASHREF_FILES = $(srcdir)/bashref.texi $(srcdir)/fdl.texi
> $(srcdir)/version.texi
> ${RM} $@
> -${DVIPS} $<
>
> -all: ps info dvi text html
> +all: info
> nodvi: ps info text html
> -everything: all pdf
> +everything: all pdf dvi text html
>
> PSFILES = bash.ps bashbug.ps article.ps builtins.ps rbash.ps
> DVIFILES = bashref.dvi bashref.ps
So the problem is that bash builds too much by default? And it's the build
output that needs to be bit-for-bit reproducible? In general, this is
impossible, since the version string changes with each new `build version'.
This patch doesn't have anything to do with the install target, which
installs the info file, man pages, and html files by default. (And if you
don't want the html files installed, run make install with `htmldir' set
to the empty string.)
> In addition, the ‘install’ rule in doc/Makefile.in would need to be
> split in ‘install-info’, ‘install-pdf’, etc. (as explained in the GCS),
> with ‘install’ depending only on ‘install-info’.
Again, that's not quite what the coding standards say. The standards say
to make sure to install the info file when you run `make install', using
the `install-info' program to do so.
> What do you think?
It's hard to say, since the proposed patch has little to do with the
subject of the message.
--
``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/
--- End Message ---
Bug#403304: Debian: bash --debugger doesn't start the debugger
On 10/12/15 4:16 PM, Nicholas Bamber wrote: > My investigations indicate that it is still true that as per Debian bug > report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403304) > --debugger does NOT start the debugger UNLESS the debugged script has a $1. We discussed this in a thread on bug-bash back in April: http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00183.html This discussion references an earlier bug report concerning whether the --debugger option should produce an error if the bashdb script is not installed. There is also an issue with bashdb misbehaving when run in an interactive shell; that was the reason for the check of $1 in the first place. Part of that thread explains why a check of $0 is not correct: since $0 is always set, a check for it has no effect. The final change that solves both problems went into the bash development branch in early May, and will be in bash-4.4. -- ``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/
Bug#771244: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 12/3/14, 9:52 AM, Askar Safin wrote: Please stop mischaracterizing the issue. It's not a bug: it's a case of konsole's mismatched expectations. Since the mechanism it uses is not documented, and relies on something in readline that is not documented, it can't fairly be called a bug. Should long text line move when user changes size of terminal or no? So? Someone else already provided a suitable answer. Continuing this conversation is not productive; it's quickly reaching dead horse territory. You might want to check out the latest devel branch snapshot, though. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/29/14 3:22 PM, Askar Safin wrote: No. You have missed the point. The point is that the secret mechanism that konsole used to use no longer works. It didn't rely on documented behavior; it relied on a side effect of the (flawed) readline-6.2 implementation. It can't really be called a bug. Okey, so, Chet, what will you say about resizing bug? Is this a bug? At this moment I doesn't ask where (readline or konsole) this bug resides. I'm just asking: is this a bug? Or long line doesn't move on resize is intended behavior? Please stop mischaracterizing the issue. It's not a bug: it's a case of konsole's mismatched expectations. Since the mechanism it uses is not documented, and relies on something in readline that is not documented, it can't fairly be called a bug. Also, mc resizes when I resize terminal window in all terminals. So, bash should move, too. That's not quite relevant. mc has apparently made the decision to allow SIGWINCH to interrupt system calls. Readline made a different decision. Both made other implementation decisions based on that. What mc's behavior proves is that it's possible to allow SIGWINCH to interrupt system calls. We already knew that. Then, if you agree this is a bug, where should it fixed? You think in konsole, right? So, you think that konsole should be aware of some readline internals and should redisplay readline prompt itself? Well, let's suppose this. But what about mc? Trying to put words in my mouth doesn't help you make a case. Yes, I understand, handlers, blah-blah. readline should not perform a lot of actions in SIGWINCH handler, so, they are deferred until read() exits. But mc has no such problems. And ssh client has no such problems (and so, it is able to pass SIGWINCH to remote program, for example, to remote mc). Did you understand anything about allowing SIGWINCH to interrupt system calls? That's the issue -- and not input system calls so much as output system calls interrupting redisplay or completion. (If you want an example of interrupted system calls causing weird errors, look back in the bash mailing list archives for reports of SIGCHLD interrupting open(2) and causing redirections to fail.) There is a change involving pselect that may improve the situation, but pselect is explicitly allowed to restart if a signal handler is installed with the SA_RESTART flag, so we will have to see how portable that is. I understand that you only use Linux, and pselect might be ok there. We will see about other platforms. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/28/14 10:34 AM, Askar Safin wrote: Doesn't seem like a bug to me. You asked your terminal emulator to clear the screen. It did so. Now you complain that it's too clean :) When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should work the same and it should clear scrollback additionally. bash 4.3 + konsole behavior is not OK for me, because I have to press Enter after Ctrl-Shift-X. :) This would make sense if the two operations did the same thing. I don't think they do; I think the Ctrl-Shift-X key sequence causes konsole to send SIGWINCH. I understand how it may look confusing, but I don't think the term has much option here. Suppose that instead of the shell, you were executing something else (eg. reading a log file). Yes, but this somehow worked before. And I press Ctrl-Shift-X in bash only. :) There is a better explanation in one of the threads I referenced in my previous message, but here's the short story: readline has always set SIGWINCH to restart system calls. It would redraw the prompt upon receipt of a SIGWINCH in previous versions because it (incorrectly) executed that code in a signal handler context. Cleaning up the code so it didn't try to execute arbitrary code in signal handlers was one of the big changes between bash-4.2/readline-6.2 and bash-4.3/readline-6.3. Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: git bisect shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? Try looking at the devel branch. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771244: bash 4.3: Clear Scrollback and Reset (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/28/14 8:17 PM, Askar Safin wrote: Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: git bisect shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? Try looking at the devel branch. Thanks. http://git.savannah.gnu.org/cgit/bash.git/commit/?id=f4f5e1c2b8fa4539e367e1f48774183d349184c5 in devel branch is commit which introduces this behavior (git bisect, again). But still this branch doesn't seem as real devel history. This is just weekly snapshots. Does bash have real SCM (non-git ones is OK)? Where is SCM you use for development? I use something local and home-grown that far predates git. The development history is a combination of the change log (CWRU/CWRU.chlog) and the git devel checkins. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740971: completion fails on file names with special characters
On 3/27/14, 4:57 PM, Uwe Storbeck wrote:
$ ls a(TAB
results in a wrong completion:
$ ls a(a
This is something different. I addressed it in my first reply in this
thread:
For instance, I believe that the problem with these unquoted special
characters is that they break words for readline, and readline passes
an empty argument to the completion function as the word to be completed.
The `(' is a character that breaks words for readline. Readline passes
an empty string to the bash completion function, which completes
it to the longest common prefix of the possible completions.
There is a difference between bash-4.2 and bash-4.3 in how it treats
this word. bash-4.3 does not interpret it the `(' as a command
delimiter (as it did in bash-4.2) because it's preceded by a character
that is not a command delimiter. bash-4.2 incorrectly treated that
construct as valid and attempted to perform command completion; since
it's a syntax error, bash-4.3 doesn't. There aren't any valid completions
for the empty string, so bash doesn't do anything and readline attempts
its default filename completion. The longest common prefix of the
possible filename completions is a, which readline inserts into the
line buffer.
Since that line, as you entered it above, is a syntax error, it's not
clear what bash should do with it (probably nothing). What do you
expect to happen?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740971: completion fails on file names with special characters
On 3/27/14, 7:11 PM, Uwe Storbeck wrote: On Mar 27, Chet Ramey wrote: Since that line, as you entered it above, is a syntax error, it's not clear what bash should do with it (probably nothing). What do you expect to happen? The same as if you would try to complete any non-existing file name, nothing? The completion should not append an a to the typed in a(. Instead the cursor should stay in the same position (after the parenthesis) and bash should beep. Yes, if bash can detect a syntax error, that's probably the best thing. When you try to complete ls ab with TAB in the same example with the two files aa and a( in a directory bash-completion handles it correctly. It only fails because of the parenthesis (and maybe also with other special characters). There is virtually nothing common between the two cases other than the fact that they are two-character strings beginning with `a'. This has nothing to do with bash-completion (maybe I should remove the debian bug address from the recipients). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740971: completion fails on file names with special characters
``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bug#742006: [bash] Incomplete grammar in manual page (compound commands)
On 3/19/14 1:29 AM, Filipus Klutiero wrote: Sorry for the last paragraph, I didn't realize that if true; then echo x; fi was a list. Thanks, the definition of compound commands is OK then. I probably developed my misunderstanding of what a list is due to the order of sections and the fact that the manpage does not define what a command is. To be fair, even the author of the info documentation got that wrong: A `pipeline' is a sequence of simple commands separated by one of the control operators `|' or `|'. Thanks. The man page says a sequence of one or more commands I'll fix the inconsistency. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742006: [bash] Incomplete grammar in manual page (compound commands)
On 3/18/14 2:23 AM, Filipus Klutiero wrote:
Package: bash
Version: 4.3-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: bug-b...@gnu.org
According to the section Compound Commands of the manual page, a compound
command is one of 11 forms listed. However, as explained in the ALIASES
section, a function definition ( function name [()] compound-command
[redirection] ) is also a compound command.
A function definition is a function definition command. The sentence
in the ALIASES section should read a function definition is itself a
command.
Multiple other forms of compound commands are not documented, for example {
if true; then echo x; fi }.
I'm not sure what this means. Group commands are compound commands, and
are documented as such.
If you want to take a look at the Posix grammar and list of compound
commands, go to
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
What's the point of this report? Is there some problem this is attempting
to address?
--
``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/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740971: completion fails on file names with special characters
On 3/12/14 11:44 PM, Filipus Klutiero wrote:
Hi Uwe,
On 2014-03-12 21:37, Uwe Storbeck wrote:
A few corrections to my last mail:
bash completion before the first letter of the file name fails at
all, even for normal file names:
$ mkdir /tmp/test cd /tmp/test touch a
$ ls TABTAB
Also not all characters where the completion after the first
letter fails are characters which bash would escape with a
backslash during the completion as the comma actually does not
get escaped by bash.
Not sure what qualifies special characters in this context.
Characters where completion does not work for me (when file
names share the same beginning, as you have mentioned before)
are:
!$'()*,:;=?[\]^`{|}
Interesting is also this example:
$ mkdir /tmp/test cd /tmp/test touch aa 'a('
$ ls aTABTAB
a( aa
So far it's ok. But:
$ ls a(TAB
results in a wrong completion:
$ ls a(a
Uwe
I can reproduce (only tested the first case). Indeed, bash-completion
appears to cause quite important bash completion problems with 4.3. This
has to be related to a similar issue reported by Albert Shih upstream (on
the mailing list, there is no upstream ITS):
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00032.html
That message is a reflection of where things currently are. It contains a
patch that will allow bash-completion to work unchanged. (In a nutshell,
bash-completion makes assumptions about what compgen will do with quoted
null arguments that changed between bash-4.2 and bash-4.3.)
I think that patch will fix most, if not all, of the bash-completion
problems. I need people to test it, since the platforms I commonly use
for development (Mac OS X, RHEL) do not install bash-completion.
For instance, I believe that the problem with these unquoted special
characters is that they break words for readline, and readline passes
an empty argument to the completion function as the word to be completed.
I'm not sure what bash-completion does with that to make it include the
previous word.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741402: [bash] Shell functions definitions may require parentheses despite function keyword
On 3/12/14 1:57 AM, Filipus Klutiero wrote: Package: bash Version: 4.3-2 Severity: minor X-Debbugs-Cc: bug-b...@gnu.org According to the manual, either the function keyword or parentheses should be sufficient to define a function: Shell Function Definitions A shell function is an object that is called like a simple command and executes a compound command with a new set of positional parameters. Shell functions are declared as follows: name () compound-command [redirection] function name [()] compound-command [redirection] This is a documentation error. When the `function' reserved word is used, and () doesn't appear, the braces are required to avoid ambiguity. It's always been like this. I will clarify the documentation. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710588: display of search string very wrongly stops when can't find any match
On 5/31/13 11:52 PM, jida...@jidanni.org wrote: Do this: C-r 1 2 3 4 5 6 7 ... You will see on your screen (reverse-i-search)`1234': or you will see more or less digits depending on your history. The point is sooner or later the digits won't reflect what the actual current search string is! There is NO POINT in not showing those digits. Plus one has to hit Backspace several times until we get back to the real digits shown. You are already ringing the bell. The user gets the message. Thanks for the suggestion. I will look at implementing this for the next version of bash. It will likely not be in bash-4.3, which is already in alpha, but may appear in subsequent development snapshots for testing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628638: [PATCH/RFC] bash.1: shopt -s checkwinsize has no effect in non-interactive shells
On 5/31/11 10:49 PM, Jonathan Nieder wrote: Explain that COLUMNS and LINES are not set automatically in non-interactive shells, and recommend direct use of the tput utility from ncurses as a replacement. Thanks for the report, though the tput recommendation doesn't belong in a manual page. It's more appropriate for an FAQ or a bash guide. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611417: set -m +m -x and the element of chance or is it race conditions?
On 1/29/11 7:33 PM, jida...@jidanni.org wrote: CR == Chet Ramey chet.ra...@case.edu writes: CR Is it a problem? Bash prints messages about signal-terminated processes -- CR at least those that don't die due to SIGINT or SIGPIPE -- when the CR shell is not interactive. Most people want to know when their jobs die CR and their scripts fail. But some don't, but also don't want to do exec 2/dev/null and take other messages to the grave with it. Plus it isn't documented, depends on having e.g., sleep 0 after it, and in general looks like one big hack. And violates the set +mb promise! Is everything you don't like that's not explicitly documented a bug? In any case, a little thought should tell you why having the shell stick around long enough to catch the child's death makes a difference. And what is the `set +mb promise'? CR (And, by the way, historical versions of sh did the same thing.) But not the oldest. Umm...yes, the oldest. The v7 Bourne shell did. In fact, since we were running 4.3 BSD back in the early days of working on bash, it's what we used as a model for this behavior. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#426990: 'test' builtin of bash returns wrong value for '! -a FILE' operation
help test says: See the bash manual page bash(1) for the handling of parameters (i.e., missing parameters). which does not really tempt me to look at the manual. You should probably ask the person who added that to Debian's version of bash. bash(1) says: Expressions may be combined using the following operators, listed in decreasing order of precedence. The phrase you're quoting appears in both the description of the [[ conditional command and the test/[ builtin. If you're quoting the latter, why omit the next sentence, which reads: The evaluation depends on the number of arguments; see below. 3 arguments If the second argument is one of the binary conditional operators listed above under CONDITIONAL EXPRESSIONS, the result of the expression is the result of the binary test using the first and third arguments as operands. The -a and -o operators are considered binary operators when there are three arguments. That answers the question. Unfortunately, the next sentence is inconsistent with that answer: If the first argument is !, the value is the negation of the two-argument test using the second and third arguments. Suggested changes: 1. Change the parenthesis in help bash to something like (e.g., operator precedence and missing parameters). Again, talk to the Debian maintainer who added it. 2. Change the second paragraph in the description in bash(1) of the test builtin to something like Expressions may be combined using the following operators. The evaluation depends on the number of arguments; see below. When 5 or more arguments are present, this list is in decreasing order of precedence. Something like that is reasonable. 3. Add the word Otherwise, before If the first argument is ! in the 3-argument case. The sentences are supposed to indicate precedence. It would actually be clearer if they were separated into bullet points, as they are in the Posix standard. I'll look at doing that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569227: ncurses-base: break handling of ctrl-c in xterm and rxvt using bash
On Tue, Feb 16, 2010 at 06:42:27AM -0500, Thomas Dickey wrote: Your shell is not likely using the parts of ncurses which would change the terminal modes. For instance, bash uses only the termcap interface. I'd look at the shell. I finally found some time to verify this. Two observations: When I start an xterm and instantly hit ctrl-c I will see some ^C^C^C until the bash is fully loaded. Afterwards ctrl-c no longer produces any reaction. Invoking a zsh from that bash gives me a shell, that handles ctrl-c as it should. My conclusion is that this must be a fault of bash. Unfortunately downgrading bash to 4.0-4 did not solve the problem. It's an interesting conclusion, but you have no data to support it. Can we maybe start with `stty -a' from a shell session having the problem? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573780: trap - SIGNAL should reset SIGNAL to SIG_DFL not to initial value
Package: bash
Version: 3.1dfsg-8
http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
If action is '-', the shell shall reset each condition
to the default value.
bash(1):
If arg is absent (and there is a single sigspec) or -, each
specified signal is reset to its original disposition (the value it
had upon entrance to the shell).
And indeed the manpage for bash describes the actual behaviour, not
the correct behaviour:
$ perl -e 'print STDERR Signal handling for SIGPIPE:
$SIG{PIPE}.\n;'
Signal handling for SIGPIPE: .
$ sh -c 'trap PIPE; exec $@' x perl -e 'print STDERR
Signal handling for SIGPIPE: $SIG{PIPE}.\n;'
Signal handling for SIGPIPE: IGNORE.
$ sh -c 'trap PIPE; exec $@' x sh -c 'trap - PIPE;
exec $@' x perl -e 'print STDERR Signal handling for SIGPIPE:
$SIG{PIPE}.\n;'
Signal handling for SIGPIPE: IGNORE.
$
If the bash behaviour is thought desirable for some reason (although I
can't imagine why) then another mechanism needs to be provided for
resetting signals to SIG_DFL, as currently this is not possible in
bash.
The bash behavior is correct. There are only two signal dispositions
a process can inherit from its parent: SIG_IGN and SIG_DFL. Posix
says that `trap' can't modify the disposition of a signal whose
inherited value is SIG_IGN, and an inherited value of SIG_DFL covers
the rest. In either case, the signal winds up with the disposition
the shell inherited.
If you look a couple of paragraphs past the sentence you quoted from Posix,
you'll find:
Signals that were ignored on entry to a non-interactive shell cannot
be trapped or reset, although no error need be reported when
attempting to do so. An interactive shell may reset or catch signals
ignored on entry.
This covers what you're trying to do. (Bash treats non-interactive and
interactive shells identically in this regard.)
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444250: Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
On 3/23/10 9:28 PM, Thomas Dickey wrote: Given that, the issue is now how to appropriately set the default value of the enable-meta variable. That's the current question, and it was the question we were considering before. Like the choice of $TERM, it's something that the user is going to have to decide. It might be dynamic. OK, thanks for your help. We've come full circle. I don't see any reason to change the status quo. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
[Summary for newly added recipients: after a recent round of upgrades, I found that typing meta-key combinations into xterm with bash as my shell resulted in non-ASCII characters rather than the expected escape sequences. Further analysis revealed that the trigger was an update to xterm's terminfo entry (from ncurses-base), which added definitions of smm and rmm despite the comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444250#40 .] Thomas Dickey dic...@his.com writes: That's already been discussed in SuSE - it's an issue with bash. It should allow the decision whether to enable meta mode to be configurable. bash's maintainer hasn't been cooperative. As of bash 4.1 (and the corresponding readline 6.1 release), there is now an enable-meta-key readline variable that has the desired effect. Bash and readline have logic (_rl_init_eightbit) to set related variables (convert-meta, input-meta, and output-meta) sanely in eight-bit locales, but always leave enable-meta-key on by default; could you please patch _rl_init_eightbit to set _rl_enable_meta = 0 in eight-bit mode? Why would I want to turn off _rl_enable_meta in eight-bit mode? It seems that's when I should want it, since it's supposed to reflect the terminal's indicating that any available meta key enables the sending of eight-bit characters when it's used. For this issue to exist, the terminal has to advertise (using km) that it has a meta key that turns on the eighth bit of characters the terminal sends when it's used as a modifier, and the smm capability has to exist to enable it. If those are both true, and the enable-meta variable is set, which it is by default, bash sends the smm string. If I'm in eight-bit mode, I want that to be on. I sent a bunch of questions last year about how xterm advertises capabilities using terminfo and how it reacts when it gets the corresponding escape sequences; those were ignored. I'm still waiting. Remember that the only way bash or any application can get to the xterm resources is through terminfo/termcap. If understanding the interaction between the two requires some remedial instruction, fire away. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444250: Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
I see (it would have been nice if Chet Ramey had responded to the bug report in October - I updated my faq to address this detail). I did. I sent the following questions (I have more, but this is a start). They were ignored, so I went on without the information. = 091006184253.aa92593...@caleb.ins.cwru.edu I'm not sure I understand the change to xterm that caused this, though. Is it that it always advertises the `km' capability and switches off the eightBitInput or eightBitControl resources when you send the `smm' string? Or does it turn on the metaSendsEscape resource? Or something else? I'm trying to understand how xterm dynamically changes its resources based on terminal escape sequences it receives. I'm not sure how to reconcile the description in http://invisible-island.net/ncurses/ncurses.faq.html#bash_met a_mode with the description in the terminfo manual page (8th bit on). I'd like to have readline do the right thing by default, even if I add a new variable to control this specific behavior. I'd also like it to interact well with the existing readline eight-bit variables. = -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444250: Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
On 3/23/10 6:24 PM, Thomas Dickey wrote: On Tue, 23 Mar 2010, Chet Ramey wrote: I see (it would have been nice if Chet Ramey had responded to the bug report in October - I updated my faq to address this detail). I did. I sent the following questions (I have more, but this is a start). They were ignored, so I went on without the information. My email says that I did respond to the mail you're quoting; that was the last on that thread in October. You didn't, actually. The last message I have from you (20091007005807.gb24...@invisible-island.net) is a response to 4acb5fd8.5080...@case.edu, an earlier message in the sequence. If you answered the questions I quoted, please resend that message and we'll go on from there. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
On 3/23/10 6:18 PM, Thomas Dickey wrote: I don't see a bunch of questions, but only about 3 lines of comments which most people would answer by reading the manpage (start with the resource description for eightBitInput). Singularly unhelpful. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444250: Bug#574396: please set enable-meta-key (_rl_enable_meta) sanely
On 3/23/10 8:18 PM, Thomas Dickey wrote: On Tue, 23 Mar 2010, Chet Ramey wrote: On 3/23/10 6:24 PM, Thomas Dickey wrote: On Tue, 23 Mar 2010, Chet Ramey wrote: I see (it would have been nice if Chet Ramey had responded to the bug report in October - I updated my faq to address this detail). I did. I sent the following questions (I have more, but this is a start). They were ignored, so I went on without the information. My email says that I did respond to the mail you're quoting; that was the last on that thread in October. You didn't, actually. The last message I have from you (20091007005807.gb24...@invisible-island.net) is a response to 4acb5fd8.5080...@case.edu, an earlier message in the sequence. If you answered the questions I quoted, please resend that message and we'll go on from there. Don't you have my email from 06 October? (If it were on the Novell bug report, it would be easier to reference). I do. The message-id I referenced is from 6 October. It didn't answer my questions. All of the features in a terminal description are optional (or advisory, depending on what term you prefer). They only tell the application whether a terminal supports a feature and/or how to achieve a given function. True. And the xterm terminfo description says it has a meta key that can be used as a modifier to send characters with the eighth bit set, and that that feature can be enabled by sending a key sequence. The point of the bug report and followup discussion was that some users prefer to switch off the mapping of eight-bit characters, to get the escape character prefixing modified keys And now they can. We moved beyond that even while discussing the previous bug report. We're talking about whether or not xterm reveals anything to the application running inside it about the current state of its resources (it doesn't) and whether it dynamically reflects changes in those resources to an application (it can't). Good enough. Given that, the issue is now how to appropriately set the default value of the enable-meta variable. That's the current question, and it was the question we were considering before. Another question is why xterm honors the smm sequence and allows the Meta key to act as an eight-bit modifier when eightBitInput and metaSendsEscape are false. Should xterm's behavior in response to terminfo sequences always be consistent, or should it depend on the current settings? man 5 terminfo If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. I agree that terminfo is a poor mechanism to use when terminal capabilities can change dynamically. Unfortunately, it's what we have. -- ``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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519165: [Fwd: Bug#519165: bash 4 regression]
Matthias Klose wrote: wouldn't this changed behaviour warrent a compatibility switch? I'm going to do what the Posix group decides. Read http://lists.gnu.org/archive/html/bug-bash/2009-06/msg00107.html for a summary; portions of which I will reproduce below. (And the line that got munged in the bug-bash archives noted the inconsistency of bash-3.2 not exiting on $@ but exiting on the variant with braces.) Subject: Bug#519165: bash 4 regression From: martin f krafft madd...@debian.org Date: Wed, 29 Apr 2009 12:19:08 +0200 $@ and $* are special, and not really variables. In any context where there are positional parameters, they are set. This is true. They're not variables; they are positional parameters. Maybe the standard is not clear, but all other shells do it the way bash has always done it, so I don't see a need to deviate from that path. There are de-facto standard, after all. There is, in fact a de facto standard, but the bash4 behavior is what the Bourne and Korn shells have always done. In fact, the only way Martin's statement is true is if all other shells means dash, since that's the only other shell I found that doesn't apply set -u to $@ and $*. A partial list of shells that honor set -u when expanding $@ and $*: bash4 all versions of the bourne shell from v7 to svr4.2 all versions of the korn shell pdksh and variants like mksh and posh ash and its descendents except dash On the other hand, Goswin von Brederlow points out that the standard is perfectly clear: '@' shall generate zero fields does not suggest shall fail to expand. Some might say it pretty clearly says that it must not fail to expand, ever. Put differently, this means that those two variables can never be undefined in the sense of set -u. Creative, but irrelevant. The key was the variables language in the Posix description of `set -u', which invalidates historical behavior. $@ and $* are not variables. We can debate this issue ad mortem infinitumque (but let's not). Fact is that this is a regression, which upstream camouflaged as a bug fix, when instead there should have been a deprecation period. Expecting everyone to change their scripts to work around bash's eclectic interpretation of $@/$* is not the way forward. Beautiful language, but incorrect. The current bash4 behavior is not an eclectic interpretation, but consistent with how shells have historically behaved. I am thus marking this bug grave as it breaks a lot of existing scripts. Can't win, can you? :-) When bash does something different from historical shell behavior, it either gets slammed because the difference exists or because people write scripts that depend on the difference. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#265182: I can confirm the bash prompt bug
Joachim Breitner wrote: I’m bitten by this bug for a while now, and I’d like to ask what the state of it is. The last mail by you, Chet, indicated that it might be fixed with 3.1, but so far it hasn’t, it seems. It still exists, and it's still low priority. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487387: [[ ... =~ ... ]] is broken when RHS is quoted
Alexis Huxley wrote:
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
[[ ... =~ ... ]] is broken when RHS is quoted
The behavior changed, intentionally, between bash-3.1 and bash-3.2.
# As described by OP, =~ has stopped working:
lasagne$ bash -c '[[ apple =~ ^(apple) ]]; echo ${BASH_REMATCH[1]}'
--- no output!
And this is how. Quoting any part of the rhs forces it to be matched
as a string.
Patch 39, which you appear to have applied, introduces a `compat31' shell
option which you may enable to restore the bash-3.1 behavior.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476519: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
[EMAIL PROTECTED] wrote: CR Does this happen only in an emacs shell-mode window? No. It happens also in xterm. Today it at least allowed me to do -c date. I did not type exit or logout. The magic hand did. # su - nobody -c date No directory, logging in with HOME=/ Sat May 3 01:03:10 CST 2008 # su - nobody -c 'sh -i' No directory, logging in with HOME=/ sh-3.2$ exit # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout FWIW, I can't reproduce this on Fedora 8, the version of Linux I have available. This really looks like a terminal process group problem -- read will return -1/EIO if the process doing the read isn't in the same process group as the terminal and the process is blocking SIGTTIN, which interactve shells do by default. Does su do anything with process groups? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476519: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
Stephane Chazelas wrote: [...] Could be a tty setting as well. stty min 0 time 10 -icanon could reproduce that if bash was built without readline I think. With readline, bash is meant to reset those min and time parameters before each prompt. Maybe it fails to do so in which case strace will tell you as well. You beat met to it. :-) Does this happen only in an emacs shell-mode window? If that is the case, then readline doesn't enter into the picture -- bash disables line editing when it can tell it's being run by emacs -- and uses read(2). read can return failure right away (-1/EAGAIN) or 0 (no data available) if it's called with the tty in non-canonical mode and those tty settings. Either value will be translated to EOF and cause the shell to exit. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442077: su + ssh + false kills $PPID?
Dan Jacobson wrote: Package: openssh-client Version: 1:4.6p1-5 Severity: normal File: /usr/bin/ssh Why does this script not finish, only when using su, and only when using ssh? # cat script su my_username_here \EOEOE set -x echo $- #no -e here, see remote=my.remote.host.here false ssh $remote false #Why does this signal the parent to bomb out? echo never got here Because ssh, like its predecessor rsh, consumes its standard input unless given the -n option. Its standard input is the same as its parent's: the contents of the here document. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Dmitry Potapov wrote: Unfortunately, you are right. I did not foresee that some shells may use dup2(open(file.txt), fileno(stdout)). It is a dirty hack, which may cause some other problems. Frankly, I am a bit surprised that bash uses printf instead of write(2). BTW, you cannot use 'printf' in signal handlers, so it seems that you cannot use 'echo' in trap commands too. Luckily, neither of these things is true. What's needed is a portable interface like BSD's fpurge(3). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Andreas Schwab wrote: Chet Ramey [EMAIL PROTECTED] writes: What's needed is a portable interface like BSD's fpurge(3). This is also available from glibc as __fpurge (likewise on Solaris). Yes, though I have an aversion to calling functions with a `__' prefix from user application code. However: These functions are nonstandard and not portable. It would be nice to have something standardized. I can certainly add yet another configure test for this -- I just wish I didn't have to. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334182: dash POSIX issues [Gentoo Bug #171630]
Herbert Xu wrote: So I still stand by my statement that script writers on Linux cannot safely rely on this construct. As it is, we have two different behaviours, one given by the Korn shell and another shared by most BSD-derived Bourne shells. I have not seen any convincing evidence that either is not compliant with respect to POSIX. Kevin's analysis seems correct to me. The bash behavior, modulo any (just-corrected) bugs, should reflect that interpretation. I'm not sure how an alternate interpretation can be rationalized. The behaviour of bash is closer to that of the Korn shell but is different enough that this construct cannot be reliably used. Maybe, maybe not. It's a bug, and there will eventually be a fixed version of bash released. It's existed since at least bash-2.05b, the earliest version of bash I have handy, so that should give you an idea of how many times it's come up in the last five years or so. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334182: dash POSIX issues [Gentoo Bug #171630]
Kevin F. Quinn wrote: I still think the standard is pretty clear. However if BSD sh has never worked like that, I don't see how the standard ended up the way it did, given it was written to document what could be relied on across existing Unix variants at the time. The Posix.2 standard (they were separate back then) predates the Almquist- derived 4.4 BSD shell. The earliest versions of the standard were based on the Korn shell and the System V sh. The first published version of Posix.2 came out in 1992, and there had been a dozen or so drafts by then; 4.4 BSD wasn't released until 1993, and Net2 didn't make enough of a ripple to affect the standard. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360793: bash -c '. /dev/enoent; whoami' unhelpful error code (forwarded from Ian Jackson)
Ian Jackson wrote: Chet Ramey writes (Re: Bug#360793: bash -c '. /dev/enoent; whoami' unhelpful error code (forwarded from Ian Jackson)): Matthias Klose wrote: The exit status should be 127, not 1. That would allow bash -c '. bogus; diff file other-file' to be distinguished from bash -c '. /dev/null; diff file other-file' There's no good reason to change this. If you want to check whether or not a file exists before trying to source it, use test -e or test -f. If you want the shell to abort if the file argument can't be read, use posix mode. ? Testing for expected error situations before carrying out some action is no substitute for proper and correct error handling if the action fails. For example, in the case I quoted, there might be all sorts of reasons why opening the file might fail even though it exists and is a file. Step back and take a look. You have to do this sort of checking no matter what if you want robust programs. Consider what would happen if the shell changed the exit status of `.' to 127 if the file argument did not exist. Since `.' is required to return the exit status of the last command executed, there's now no difference between . notthere and . existing-file where `existing-file' ends with `notthere' or any other command that's not found. In general, trying to intuit something besides an error occurred from a non-zero exit status works only in a very few cases. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362010: bash: output without trailing newline makes prompt behave oddly (forwarded from Yunfeng Wang)
Matthias Klose wrote: Bug#362010: bash: output without trailing newline makes prompt behave oddly The next version will be better about this, but the original poster should keep in mind that readline not knowing where it is on the line will eventually result in display errors. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360793: bash -c '. /dev/enoent; whoami' unhelpful error code (forwarded from Ian Jackson)
Matthias Klose wrote: The exit status should be 127, not 1. That would allow bash -c '. bogus; diff file other-file' to be distinguished from bash -c '. /dev/null; diff file other-file' There's no good reason to change this. If you want to check whether or not a file exists before trying to source it, use test -e or test -f. If you want the shell to abort if the file argument can't be read, use posix mode. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358831: bash operand errors (forwarded from C.Y.M)
Matthias Klose wrote: C.Y.M writes: Reverting back to bash 3.0 fixes the problem. It seems bash 3.1 has broken the way the arrays are read. Once again bitten by using a too-general function for consistency across different expansions :-). I will be releasing a patch for this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357260: bash-doc: GFDL documentation with cover texts (forwarded from Sven Joachim)
Matthias Klose wrote: Debian recently decided about distribution of GFDL documents in Debian (http://www.us.debian.org/News/2006/20060316). Here is the corresponding bug report for bash. - would you consider removing the section about the cover texts? Sure, I'll consider it. On the other hand, I find it interesting that Debian would refuse to distribute an entire manual simply because, for instance, I would like a dedication to remain unmodified. Is it that important to the ideological purists that they retain the option to delete, again for example, a dedication I might make to my wife and children? That's a lot of baby to be thrown out for very little bathwater. - please could you clarify on the GFDL version? I'll change the text to specify 1.2. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345861: [parameter expansion] Array member length expansion fails with nested index expression (forwarded from Jan C. Nordholz)
Matthias Klose wrote: Subject: Bug#345861: [parameter expansion] Array member length expansion fails with nested index expression Thanks, I already fixed it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345473: set bell-style none in /etc/inputrc has no effect (forwarded from [EMAIL PROTECTED])
Matthias Klose wrote: Subject: Bug#345473: set bell-style none in /etc/inputrc has no effect From: [EMAIL PROTECTED] Date: Sat, 31 Dec 2005 11:37:56 -0800 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: readline-common Version: 5.1-5 setting set bell-style none in /etc/inputrc has no effect but set bell-style visible does have an effect This has nowhere near enough information to do anything. The output of `bind -v' (or some other application specific way of listing readline variables and values)? What's /etc/inputrc look like? How about any other readline input files? One thing that would certainly make a difference is whether or not you set the `prefer-visible-bell' variable, since that can override bell-style. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342868: A fix for the actual bash defect (forwarded from Mike Stroyan)
Matthias Klose wrote: Subject: Bug#342868: A fix for the actual bash defect Thanks; I had gotten this same report some time ago. This will be released as a patch to bash-3.1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343471: bash: In the command line, problem when the line reaches the last column of the terminal
Vincent Lefevre wrote: On 2005-12-16 10:42:52 +0100, Vincent Lefevre wrote: Same problem after removing by .bash_profile and .bashrc files. But this problem doesn't occur when executing bash --norc. Still without my .bash_profile and .bashrc files: When I start bash with bash --rcfile /etc/bash.bashrc, the problem occurs. But if I type bash --norc then source /etc/bash.bashrc, it doesn't occur. What's the difference between them? The difference is that readline initializes itself after /etc/bash.bashrc is read in the former case, and before it's read in the latter. That would seem to point to /etc/bash.bashrc. Your initial message leads me to believe that readline is getting wrong information when it initially reads the terminal capabilities, and the value for `xn' is wrong. What's in debian's /etc/bash.bashrc, and has it been changed on your system? (I can't reproduce this at all, so someone else who can will have to feed information into this process.) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343471: bash: In the command line, problem when the line reaches the last column of the terminal
Vincent Lefevre wrote: On 2005-12-16 13:47:21 -0500, Chet Ramey wrote: Vincent Lefevre wrote: When I start bash with bash --rcfile /etc/bash.bashrc, the problem occurs. But if I type bash --norc then source /etc/bash.bashrc, it doesn't occur. What's the difference between them? The difference is that readline initializes itself after /etc/bash.bashrc is read in the former case, and before it's read in the latter. That would seem to point to /etc/bash.bashrc. Possibly another problem: it seems that --rcfile is buggy. dixsept:~ bash --norc bash-3.1$ dixsept:~ bash --rcfile /dev/null [EMAIL PROTECTED]:~$ Shouldn't I have got the same prompt? Nope. Debian compiles bash to source /etc/bash.bashrc at startup, before the user rcfile is sourced. If --norc is supplied, that is suppressed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343477: gdb: segfault when delete pressed (forwarded from Daniel Jacobowitz)
Matthias Klose wrote: Subject: Re: Bug#343477: gdb: segfault when delete pressed Yeah, it's a bug in readline. Andreas Schwab posted a patch to bug-bash that was just about perfect except it was in unidiff format. Something very close to that will be readline-5.1 patch 1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343128: libreadline5: Ignoring terminal control characters for prompt length also broken in irb (forwarded from Aaron Schrab)
Matthias Klose wrote: Subject: Bug#343128: libreadline5: Ignoring terminal control characters for prompt length also broken in irb From: Aaron Schrab [EMAIL PROTECTED] Date: Wed, 14 Dec 2005 09:54:41 -0600 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: libreadline5 Version: 5.1-1 Followup-For: Bug #343128 I just noticed that this bug also affects irb (from the irb1.8 package, version 1.8.3-3). Since Ruby's readline interface doesn't currently provide a way to access the RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE values, I simulate this manually by including \001\001 and \001\002 in my IRb prompt. This works fine with libreadline5 5.0-11, but with the current version, I get the same behaviour as I saw in psql. What does this mean? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343128: libreadline5: Ignoring terminal control characters for prompt length also broken in irb (forwarded from Aaron Schrab)
Matthias Klose wrote: Subject: Bug#343128: libreadline5: Ignoring terminal control characters for prompt length also broken in irb From: Aaron Schrab [EMAIL PROTECTED] Date: Wed, 14 Dec 2005 09:54:41 -0600 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: libreadline5 Version: 5.1-1 Followup-For: Bug #343128 I just noticed that this bug also affects irb (from the irb1.8 package, version 1.8.3-3). Since Ruby's readline interface doesn't currently provide a way to access the RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE values, I simulate this manually by including \001\001 and \001\002 in my IRb prompt. This works fine with libreadline5 5.0-11, but with the current version, I get the same behaviour as I saw in psql. OK, I saw the original report. Before I start checking, why are you adding the extra '\001' to the start and end ignore values? Does irb handle that specially somehow? (Bash does it because it has to quote those characters internally, but those are not part of what readline understands.) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332635: libreadline5: readline works incorrectly with non-ASCII input (forwarded from [EMAIL PROTECTED])
Matthias Klose wrote: Subject: Bug#332635: libreadline5: readline works incorrectly with non-ASCII input This is fixed the right way in readline-5.1. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331381: [PATCH] segmentation fault due to gcc optimization and longjmp (forwarded from Jim Paris)
Matthias Klose wrote: Subject: Bug#331381: [PATCH] segmentation fault due to gcc optimization and longjmp From: Jim Paris [EMAIL PROTECTED] Date: Mon, 03 Oct 2005 02:36:18 -0400 Thanks. I fixed it a different way when the original bug report was posted (by slightly rearranging code). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310012: dynamic-complete-history documentation change
It seems that the binding for Alt-Tab changed from dynamic-complate-history to tab-insert around Bash 3.0. More precisely, bash declined to override the default binding, which is tab-insert. I have restored the previous behavior. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292751: command -v prints function names (forwarded from Thomas Hood)
Matthias Klose wrote: Subject: Bug#292751: command -v prints function names From: Thomas Hood [EMAIL PROTECTED] Date: Sat, 29 Jan 2005 15:00:35 +0100 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: bash Version: 3.0-5 Severity: normal The following log shows that command -v prints the name of a shell function even though the man page says that shell functions are supposed to be excluded from the search. The man page does not say that, though it's not obvious. Rather than specify two different builtins, POSIX chose to standardize `command' with two essentially independent modes. When used to run a command, it skips shell function lookup. When invoked with `-v' or `-V', it behaves like `type', and shell functions are included. If you look at the POSIX description of `-v' and `-V', you'll see that shell functions are explicitly included. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296099: bash: 'help if': confusing text (forwarded from A Costa)
Matthias Klose wrote: Looks ok for me, but then, I'm not a native speaker ... I've already clarified that the `exit status' the last sentence refers to is the exit status of the entire `if' statement. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298889: unset var with 2.05b.0(12)-release (forwarded from digamma)
Matthias Klose wrote: Original Report: bash: unset returns 0 when unsetting a variable that has not been set I interpret POSIX to require this behavior. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299928: bash: negative exit status are buggy
Matthias Klose wrote: matthieu castet writes: Package: bash Version: 3.0-14 Severity: normal Hi, Bash accept negative exit status, I don't now if it is normal (dash or posh don't accept it.) But even if there are accepted, the return value is wrong : $ bash -c exit -1; echo $? 255 bash -c exit -10; echo $? 246 I don't see anything, why this should be disallowed, the behaviour is the same as in zsh. The exit status is anded with 0377, see exit(3). There's no bug here. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303113: bash: CDPATH in POSIX mode breaks cd builtin if symlinks exist (forwarded from T. Perkins)
Matthias Klose wrote: Subject: Bug#303113: bash: CDPATH in POSIX mode breaks cd builtin if symlinks exist This is really poorly worded. The bug report has nothing to do with symbolic links. The `problem' is that when in posix mode, bash doesn't try the current directory if no directory in CDPATH yields a valid directory name to change to. I interpret POSIX to require that. If you want bash to fall back to the current directory, include `.' as the last entry in CDPATH. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305485: bash: exec -a name does not rename $0 (forwarded from [EMAIL PROTECTED])
Matthias Klose wrote: as a test case i createa bash script: #!/bin/bash echo $0 and call it : $ (exec -a name ./a) the output is ./a I fee the severity of this bug is normal though it may be a problem having a bug in such a core function of bash. Is it really a bug or is the feature obsolete ? Neither. Bash really does invoke the command with argv[0] set to name. However, it's an executable shell script, so the kernel actually turns the command into /bin/bash ./a. At that point, normal shell script processing takes over, and $0 is set to the name of the script. The same thing happens if you omit the leading `#!/bin/bash', since POSIX requires bash to behave the way the kernel does. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323300: bash: \kill not invoke /bin/kill
Matthias Klose wrote: You write: \kill can not invoke /bin/kill while \time invoke /usr/bin/time time is flagged as a shell keyword, kill as a shell builtin. Please use command time or command kill if you want to call the command. Not sure, if that is a bug at all. Matthias is correct about `time' being a reserved word, so there's no bug here. However, since `command' only inhibits shell function lookup, `command kill' will still invoke the builtin. If you want to invoke the executable `kill', you'll need to use its full pathname. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327274: bash: Empty strings are wrongly translated (forwarded from Jim Paris)
Matthias Klose wrote: Subject: Bug#327274: bash: Empty strings are wrongly translated From: Jim Paris [EMAIL PROTECTED] Date: Thu, 08 Sep 2005 17:52:20 -0400 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: bash Version: 3.0-16 Severity: minor Tags: l10n Bash wraps empty strings in N_(). In a PO file, the empty string is the header message, and so when they're translated, the header gets inserted. For example: Bash-3.1 generates translatable strings from the help text differently, and doesn't generate any N_() sequences into builtins.c. There aren't any other places in the 3.1 source where that occurs. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294078: bash: wait neglects short-lived children (POSIX violation) (forwarded from Aaron M. Ucko)
Subject: Bug#294078: bash: wait neglects short-lived children (POSIX violation) Package: bash Version: 3.0-14 Severity: normal POSIX/SUS specifies that shells should keep track of children that have already exited [up to a limit of sysconf(_SC_CHILD_MAX)] for use by the wait builtin, to avoid possible race conditions. However, bash only supports waiting for children that are still alive, even when invoked with --posix. The current development version of bash-3.1 behaves as I think you want: z3.local(2)$ cat x2 exit 125 e=$! sleep 2 wait $! echo $? wait $e echo $? wait $e echo $? z3.local(2)$ ./sh ./x2 0 125 125 It's an extension. Bash is allowed to discard the status of terminated processes after the calling shell script obtains them via wait, and bash-3.0 does so when job control is not active. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#282799: bash: Completion of fd redirect after find command limited to directories (forwarded from Lionel Elie Mamane) (forwarded from Ian Macdonald)
find foo ask for autocompletion there, only directories are taken into account. ls foo or cat foo autocomplete to all filenames (directories and non-directories), as it should. This is a limitation of the completion mechanism. There's no easy way to detect redirection at arbitrary positions on the command line and act accordingly. To do so would require each command completion function to handle redirection internally. A more generic solution is required at the bash level itself. And what do you suggest that generic solution should be? Don't call the programmable completion code at all if the previous token appears to be a redirection? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265182: this is an actual bash bug, here is how to reproduce (forwarded from Wesley J. Landaker)
Matthias Klose wrote: Subject: Bug#265182: this is an actual bash bug, here is how to reproduce From: Wesley J. Landaker [EMAIL PROTECTED] Date: Tue, 08 Feb 2005 19:54:07 -0700 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: bash Version: 3.0-14 Followup-For: Bug #265182 The issue is that prompts with embedded escape sequences whose final line extended beyond a single line on the screen do not wrap correctly. The actual issue is prompts extending more than two physical screen lines with invisible characters on the first and second screen lines. It will probably be fixed someday, but not before bash-3.1 comes out. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310598: bash:[completion] renders set unusable (forwarded from Eddy Petrisor) (forwarded from Ian Macdonald)
It would be nice if there were an option to set to display the environment minus any defined shell functions. Perhaps this could be suggested to the bash maintainer, Chet Ramey. When bash is in posix mode, `set' displays variables only, without shell functions. You can easily write a shell function to toggle the value of posix mode around a call to `set'. If it's only the environment you're interested in, use `export -p' instead of `set'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283702: Race condition when writing ~/.bash_history (forwarded from Cyril Bouthors)
Matthias Klose wrote: [severity was lowerd in the Debian BTS] I'm not inclined to do anything about this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320036: bash exits 0 on errors reading stdin (and perhaps other scripts) (forwarded from Ian Jackson)
Matthias Klose wrote: Subject: Bug#320036: bash exits 0 on errors reading stdin (and perhaps other scripts) No shell behaves as the submitter describes. Read errors are translated to EOF, and the shell exits. The exit value is $?, which is changed by the last command (pipeline) executed or by a signal. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291840: bash: segfault on variable assignment (forwarded from Joe Pfeiffer)
Matthias Klose wrote: Subject: Bug#291840: bash: segfault on variable assignment From: Joe Pfeiffer [EMAIL PROTECTED] Date: Sun, 23 Jan 2005 09:00:52 -0700 To: Debian Bug Tracking System [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: bash Version: 3.0-13 Severity: normal The command IFS=$(echo -e \255) (which is found in the burncdda shell script) causes a seg fault. The same command does not have a problem in version 2.05b-24 I can't reproduce this with bash-3.0 (all released patches) on MacOS X, FreeBSD, or Red Hat 8. A stack traceback would be helpful. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291840: bash: segfault on variable assignment (forwarded from Joe Pfeiffer)
Matthias Klose wrote: Chet Ramey writes: Matthias Klose wrote: The command IFS=$(echo -e \255) (which is found in the burncdda shell script) causes a seg fault. The same command does not have a problem in version 2.05b-24 I can't reproduce this with bash-3.0 (all released patches) on MacOS X, FreeBSD, or Red Hat 8. A stack traceback would be helpful. (gdb) run Starting program: /home/packages/bash/bash-3.0/build-bash/bash [EMAIL PROTECTED]:/home/packages/bash/bash-3.0/build-bash$ IFS=$(echo -e \255) Program received signal SIGSEGV, Segmentation fault. 0x41092dec in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x41092dec in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x080867d0 in setifs (v=0x8102208) at ../bash/subst.c:6955 There's no call to memcpy in setifs(), and the line numbers are off. Are you sure this is bash3 patch 16? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291293: bash: German translation of Alarm clock is misleading (forwarded from Philipp Meier)
Matthias Klose wrote: I agree with the bug submitter ... I probably would too, if I were fluent in German, but since the message comes from whatever translation the system has for sys_siglist[SIGALRM], I can't see how it's a bash problem. Bash doesn't compile in its own sys_siglist unless libc doesn't provide one, and I don't have any translations for its messages. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
