On 07/09/2023 19:46, Eric Blake wrote:
On Thu, Sep 07, 2023 at 11:53:54PM +0700, Robert Elz wrote:
And for those who have been following this issue, the new text for
the forthcoming POSIX version has removed any mention of obsoleting
%b from printf(1) - instead it will simply note that there is
Currently `trap` has no way to set a signal to the system default.
Rather `trap - PIPE` for example sets the signal handling to
the value it have upon entrance to the shell. It's common enough
for systems to disable SIGPIPE, so it would be useful to
support a shell wrapper that would renable stand
On 14/03/18 00:22, Pierre Gaston wrote:
> On Mon, Jan 26, 2015 at 6:05 PM, Pádraig Brady wrote:
>
>> On 26/01/15 13:43, Greg Wooledge wrote:
>>> On Sun, Jan 25, 2015 at 08:11:41PM -0800, garegi...@gmail.com wrote:
>>>> As a programming language which paradigms
On 10/08/15 05:55, Eric Blake wrote:
> On 08/10/2015 02:18 AM, Juanma wrote:
>
>> Here is another point I find confusing: I thought a "shell builtin" didn't
>> have a separate binary executable file, like 'cd' (which cd => fail),
>
> Actually, POSIX requires that there be a separate 'cd' binary,
On 24/03/17 04:57, Greg Wooledge wrote:
> On Thu, Mar 23, 2017 at 10:14:01PM -0700, Pádraig Brady wrote:
>> OK let's not derail this into a discussion specific to errexit.
>> Can we please improve things?
>> You say to not use errexit, and instead use `|| exit 1` where ap
On 23/03/17 09:34, Greg Wooledge wrote:
> On Thu, Mar 23, 2017 at 08:50:45AM -0700, Pádraig Brady wrote:
>> I was bitten by this again when combined with set -e.
>> I.E. this script doesn't finish:
>>
>> #!/bin/bash
>> set -o errexit
>> set -o pipefail
&
On 15/02/15 14:14, Pádraig Brady wrote:
> On 15/02/15 21:59, Daniel Colascione wrote:
>> On 02/15/2015 01:48 PM, Chet Ramey wrote:
>>> On 2/13/15 12:19 PM, Pádraig Brady wrote:
>>>> I was expecting bash to handle SIGPIPE specially here,
>>>> as in this
On 18/07/16 14:59, Greg Wooledge wrote:
> On Mon, Jul 18, 2016 at 10:22:46AM +0200, walter harms wrote:
>> ( ./a.out 2>&1 )
>> hallo 5
>> hallo 6
>> hallo 7
>> hallo 8
>> hallo 9
>
> (snip)
>
>> ./a.out >xx 2>&1
>> cat xx
>> hallo 6
>> hallo 8
>> hallo 5
>> hallo 7
>> hallo 9
>
> Looks like a
On 04/11/15 13:47, Chet Ramey wrote:
> On 11/3/15 7:44 PM, Keith Thompson wrote:
>> The shell-expand-line command (bound to Escape-Ctrl-E) incorrectly removes
>> quotation marks from
>> the command line, often resulting in a command that differs from what the
>> user intended to type.
>
> This is
On 24/09/15 07:20, Stephane Chazelas wrote:
> 2015-09-24 07:01:23 +0100, Stephane Chazelas:
>> 2015-09-23 21:27:00 -0400, Chet Ramey:
>>> On 9/19/15 5:31 PM, Stephane Chazelas wrote:
>>>
In case it was caused by some Debian patch, I recompiled the
code of 4.3.42 from gnu.org and the one f
On 17/09/15 18:20, Greg Wooledge wrote:
> On Thu, Sep 17, 2015 at 11:50:44AM -0500, Brian Carpenter wrote:
>> While fuzzing GNU bash version 4.3.42(1)-release
>> (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I
>> stumbled upon a 4-byte 'script' that triggers a null ptr deref
On 01/07/15 22:48, Stephane Chazelas wrote:
> 2015-07-01 22:19:10 +0300, Ilya Basin:
>> Hi list.
>>
>> Want to read whole stdin into variable.
>> Don't want to spawn new processes (cat).
> [...]
>
> Note that
>
> $( execute /bin/cat in that process, it does the reading (from
> file) and writing (
On 30/04/15 23:08, Trammell Hudson wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
On 15/02/15 21:59, Daniel Colascione wrote:
> On 02/15/2015 01:48 PM, Chet Ramey wrote:
>> On 2/13/15 12:19 PM, Pádraig Brady wrote:
>>> I was expecting bash to handle SIGPIPE specially here,
>>> as in this context it's informational rather than an indication of err
I was expecting bash to handle SIGPIPE specially here,
as in this context it's informational rather than an indication of error.
I.E. if a command to the right actually does fail
the status is set to that fail and the resulting SIGPIPEs
to the left are inconsequential to the status.
If no command f
zsh behaves as I expected:
% : | tee >(md5sum) | sha1sum
da39a3ee5e6b4b0d3255bfef95601890afd80709 -
d41d8cd98f00b204e9800998ecf8427e -
bash though seems to connect the stdout of the process substitution
to the pipeline, which seems like a bug:
$ : | tee >(md5sum) | sha1sum
253a7a49edee354f35b2e4
On 10/02/15 09:00, Vladimir Kanazir wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='l$
> uname output: Linux canny 3.13.0-34-generic #60-
On 06/02/15 21:13, Eric Blake wrote:
> Chet,
>
> I've noticed that your 'devel' branch in bash.git is rather messy;
> basically lots of commits that snapshot the state of a directory, then a
> followup commit that removes leftovers and stray files. If you were to
> set your .gitignore file (to ma
On 26/01/15 13:43, Greg Wooledge wrote:
> On Sun, Jan 25, 2015 at 08:11:41PM -0800, garegi...@gmail.com wrote:
>> As a programming language which paradigms does bash support. Declarative,
>> procedural, imperative?
>
> This belongs on help-b...@gnu.org so I'm Cc'ing that address.
>
> Shell scrip
On 28/11/14 13:02, Greg Wooledge wrote:
> On Fri, Nov 28, 2014 at 10:25:52AM +0600, Sergei Tokaev wrote:
>> Hi out there. Will it be good to add json support in bash internally. As
>> in variable declarations: decalre "-j" "{"variable":"value"}"
>
> This doesn't seem like an appropriate addition t
On 10/30/2014 07:46 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> * paste into the text editor invoked by the `edit-and-execute-command' key
>> binding (C-xC-e in emacs mode), edit the command if desired, and have the
>> shell automatically execute the contents of the editing buffer when the
>>
On 10/29/2014 09:42 PM, Daniel Colascione wrote:
> On 10/29/2014 09:35 PM, Pádraig Brady wrote:
>> On 10/27/2014 10:35 PM, Daniel Colascione wrote:
>>
>>> +@item enable-bracketed-paste
>>> +@vindex enable-bracketed-paste
>>> +If set to @samp{on} and
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
> +@item enable-bracketed-paste
> +@vindex enable-bracketed-paste
> +If set to @samp{on} and the terminal supports bracketed paste mode,
> +configure it to insert each paste into the editing buffer as a string
> +instead of treating the characters p
On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
> Hello Chet,
>
> Re: testing for Shellshock... would like your feedback... specifically,
> regarding the possibility of human-directed combinatorial testing to find
> this Bash vulnerability...
Sounds like how Michal Zalewski found the re
On 07/30/2014 07:48 PM, Chet Ramey wrote:
> On 7/30/14, 2:44 PM, Notes Jonny wrote:
>> On 7 Jul 2014 19:47, "Eric Blake" wrote:
>>>
>>> On 07/07/2014 12:34 PM, Chris Down wrote:
Hi Jon,
As is standard with other buitins, umask is documented at `help umask`:
>>>
>>> That said, POSIX
On 04/06/2014 12:56 PM, Dan Douglas wrote:
> On Sunday, April 06, 2014 01:24:58 PM Jan Novak wrote:
>> To solve this problem I suppose to add "wide" switch to printf
>> or to add "%S" format (similarly to wprintf(3) )
>
> ksh93 already has this feature using the "L" modifier:
>
> ksh -c "printf
On 03/25/2014 02:12 PM, xeon Mailinglist wrote:
> For each file inside the directory $output, I do a cat to the file and
> generate a sha256 hash. This script takes 9 minutes to read 105 files, with
> the total data of 556MB and generate the digests. Is there a way to make this
> script faster?
On 03/25/2014 01:57 PM, Greg Wooledge wrote:
> On Tue, Mar 25, 2014 at 08:24:13PM +0900, Kusanagi Kouichi wrote:
>> Description:
>> Bash's builtin printf cannot write more than one line to
>> /proc/pid/uid_map because printf writes one line at a time
>> and uid_map can be written onl
On 01/09/2014 07:19 PM, Chet Ramey wrote:
> On 1/9/14 12:42 PM, Ondrej Oprala wrote:
>> Hi, I investigated this bug report:
>> https://bugzilla.redhat.com/show_bug.cgi?id=987975
>> and found out that some of bash's builtins (source at the very least) do
>> not canonicalize
>> pathnames given as arg
On 5/21/12 3:42 PM, Chet Ramey wrote:
> On 5/21/12 3:27 PM, Aharon Robbins wrote:
> > This is why I started the Campaign For Rational Range Interpretation,
> > now part of gawk and I believe in the most recent grep also, which
> > returns us to the sane days of yesteryear, where [a-z] got only lowe
On 03/26/2013 03:23 PM, Chet Ramey wrote:
> On 3/25/13 6:45 PM, Pádraig Brady wrote:
>
>> OK thanks for the pointer.
>> So the race is narrowed rather than closed?
>> As we have:
>>
>> execute_disk_command()
>> {
>>
On 03/25/2013 02:55 PM, Chet Ramey wrote:
> On 3/25/13 10:34 AM, Pádraig Brady wrote:
>
>> I've confirmed that bash 4.3 alpha doesn't have the issue.
>> Well I can't reproduce easily at least.
>> I didn't notice a NEWS item corresponding to it tho
On 02/18/2013 02:39 AM, Chet Ramey wrote:
> On 2/17/13 7:46 PM, Pádraig Brady wrote:
>
>>>> I notice the following will wait for 5 seconds for
>>>> the timeout process to end with SIGALRM, rather than
>>>> immediately due to kill sending the SIGTERM.
>
On 11/28/11 8:34 AM, Chet Ramey wrote:
> On 11/28/11 4:48 AM, Roman Rakus wrote:
> > On 11/28/2011 06:28 AM, Mike Frysinger wrote:
> >>> I don't think I'll push every change to git as soon as it happens, but
> >>> > I'm thinking about fairly frequent commits to a `bash-devel' sort of
> >>> > tree
On 02/17/2013 10:00 PM, Chet Ramey wrote:
On 2/9/13 12:02 AM, Pádraig Brady wrote:
$ rpm -q kernel glibc bash
kernel-2.6.40.4-5.fc15.x86_64
glibc-2.14.1-6.x86_64
bash-4.2.10-4.fc15.x86_64
I notice the following will wait for 5 seconds for
the timeout process to end with SIGALRM, rather than
On 02/10/2013 08:30 PM, Chet Ramey wrote:
On 2/9/13 12:02 AM, Pádraig Brady wrote:
$ rpm -q kernel glibc bash
kernel-2.6.40.4-5.fc15.x86_64
glibc-2.14.1-6.x86_64
bash-4.2.10-4.fc15.x86_64
I notice the following will wait for 5 seconds for
the timeout process to end with SIGALRM, rather than
$ rpm -q kernel glibc bash
kernel-2.6.40.4-5.fc15.x86_64
glibc-2.14.1-6.x86_64
bash-4.2.10-4.fc15.x86_64
I notice the following will wait for 5 seconds for
the timeout process to end with SIGALRM, rather than
immediately due to kill sending the SIGTERM.
$ timeout 5 sleep 10& pid=$!; echo $pid >&
On 01/30/2013 11:05 PM, Benny Amorsen wrote:
Apparently ping has now started interpreting its command line arguments
depending on locale. I.e. ping -i 0.1 no longer works in locales where
comma is the decimal separator.
This makes it difficult to call system commands. The only workaround is
to s
Happens on x86_64 with 4.2.10(1) and 4.2.42(2) at least
The following (done in a subshell to avoid killing the current shell)
demonstrates it:
$ ($((-2**63/-1)))
Floating point exception (core dumped)
thanks,
Pádraig.
tags 6377 + notabug
On 08/06/10 14:48, Iosif Fettich wrote:
> (I'm not sure if this a bash or a coreutils issue).
>
> ls [A-Z]*
>
> doesn't work as expected/documented.
The logic is in bash but it's not an issue.
It's using the collating sequence of your locale
$ touch
Chet Ramey wrote:
> Pádraig Brady wrote:
>> Original Message
>> Date: Tue, 07 Oct 2008 11:55:51 +0100
>> From: Pádraig Brady <[EMAIL PROTECTED]>
>> To: Chet Ramey <[EMAIL PROTECTED]>
>> CC: [EMAIL PROTECTED]
>>
>> I was
Original Message
Date: Tue, 07 Oct 2008 11:55:51 +0100
From: Pádraig Brady <[EMAIL PROTECTED]>
To: Chet Ramey <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
I was just discussing bit shifting with Tim Hockin using shell
arithmetic expansion, and he pointed out that bash
42 matches
Mail list logo
