On 2022-04-11 14:52:50 -0400, Chet Ramey wrote:
> It sounds like there are three cases.
>
> 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow
>length modifiers for the printf utility), use long double. This would
>work in both default and posix modes.
>
> 2. In posi
On 2022-04-29 16:16:28 -0700, Paul Eggert wrote:
> On 4/29/22 13:04, Chet Ramey wrote:
> > I think I'm going to stick with the behavior I proposed, fixing the POSIX
> > conformance issue and preserving backwards compatibility, until I hear more
> > about whether backwards compatibility is an issue
With bash 5.2.15(1)-release under Debian (bash 5.2.15-2+b6 package),
on one of my machines:
$ bash -c 'echo $?'
0
$ bash
vlefevre@cventin:~$ echo $?
0
$ bash ; echo $?
vlefevre@cventin:~$ exit
exit
0
and on another one:
$ bash -c 'echo $?'
0
$ bash
vinc17@zira:~$ echo $?
1
$ bash ; echo $?
v
Hi,
For reports concerning the bash manual, the tarballs (5.2, 5.2.15)
and the Git repository say to Chet Ramey's address (both in the
man page and in the HTML file). But
https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html
says "Please send all reports concerning this manual
On 2023-10-17 10:16:35 -0400, Chet Ramey wrote:
> On 10/13/23 9:18 AM, Vincent Lefevre wrote:
> > The difference seems to be due to the exit status of the last command
> > of the .bashrc file. But this is undocumented.
>
> How so? The exit status ($?) is the status of "
It seems that $COMP_WORDBREAKS annoys users when filenames contain
one of its characters:
http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00034.html
http://lists.gnu.org/archive/html/bug-bash/2006-09/msg00019.html
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00163.html
and my b
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
In error messages, raw non-printable characters from arguments should
not be output without transformation, at least if this is on a terminal.
If stderr has been redirected, this is more a matter of choice.
An example: type "cd /^M" where ^M is a CR character (e.g. obtained by
typing ^V ^M). One g
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='powerpc-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/lo
On 2006-01-26 23:34:31 -0700, Bob Proulx wrote:
> Vincent Lefevre wrote:
> > An EXIT trap is executed when the process is killed, e.g. by the
> > SIGTERM signal, which breaks traditional sh compatibility
>
> A lot of POSIX required behavior breaks traditional Bourne s
On 2006-10-12 10:47:38 +0200, Com MN PG P E B Consultant 3 wrote:
> Does someone know how to deal with the following situation?
>
> Very often I do the following pattern:
>
>(1) rlogin to a foreign host
>(2) Invoke a subshell (for example because I'm setting a Clearcase
> View)
Is it a s
The following has been tried on OpenSUSE 10.2 and Mac OS X 10.4.11.
When run by sshd, bash doesn't behave consistently:
1. bash sources the init files when one uses "ssh ".
2. bash doesn't do that when one uses "ssh -t ".
According to the bash man page, (1) is correct and (2) is incorrect
(
On 2007-12-05 14:31:33 -0500, Chet Ramey wrote:
> No. sshd is not the `remote shell daemon'. The remote shell daemon
> the man page speaks of runs on port 514 and is named either `rshd'
> or `remshd'.
The sshd man page says:
sshd (OpenSSH Daemon) is the daemon program for ssh(1). Together
On 2007-12-04 22:56:21 -0500, Chet Ramey wrote:
> Bash does 1 if (and only if) it can detect it's being run with its
> stdin connected to a socket. `ssh -t' intentionally defeats that.
> There is other checking that SSH_SOURCE_BASHRC enables: looking for
> SSH_CLIENT or SSH2_CLIENT.
So, will SSH_
On 2007-12-05 22:30:45 -0500, Chet Ramey wrote:
> Vincent Lefevre wrote:
> > My main complaint is that bash behaves differently when one uses
> > "ssh " and "ssh -t ". Something needs to
> > be done to make these commands consistent.
>
> Such
I get the following errors with bash 3.2.39 under Debian/unstable:
bash -c 'alias a="echo OK >&2"
a
> /dev/null a'
bash: line 1: a: command not found
bash: line 2: a: command not found
$ bash --posix
bash-3.2$ alias a="echo OK >&2"
bash-3.2$ a
OK
bash-3.2$ > /dev/null a
bash: a: command not fou
On 2009-02-24 19:32:05 -0500, Paul Jarc wrote:
> Vincent Lefevre wrote:
> > I get the following errors with bash 3.2.39 under Debian/unstable:
> >
> > bash -c 'alias a="echo OK >&2"
> > a
> > > /dev/null a'
> > bash
On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
>
> For example, true='() { false;}' or grep='() { /bin/id;}' ...
Yes, and BTW, I don't think this is POSIX co
In article ,
lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
> For example, true='() { false;}' or grep='() { /bin/id;}' ...
Yes, and BTW, I don't think this is POSIX compliant:
8.1
19 matches
Mail list logo
