Hi,
with 4.3.48 the line
T="";echo ">${T//*/ }<"
leads to
><
but with 4.4.23 the correct result is given back
> <
in the git repro I do not find any useful login entry for this
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimm
On 9/20/18 7:39 PM, Jeremy Townshend wrote:
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> The behaviour of the "trap" builtin command changes merely by printing
> the
> list of commands associated with each signal (trap command issued
> without
>
The man page of bash (Special Parameters section) says:
? expands to the exit status of the most
recently executed foreground pipeline.
Nevertheless, background commands also modify the
value of this variable.
Example:
esoriano@omac:~$ false
esoriano@omac:~$ sleep 2 &
(wait 3 s
According to the manual:
(I) Typing the suspend character (typically ^Z, Control-Z)
while a process is running causes that process to be
stopped and returns control to bash.
(II) An OR list has the form
command1 || command2
command2 is executed if and only if com
On Fri, Sep 21, 2018 at 01:23:57PM +0200, esori...@gsyc.urjc.es wrote:
> The man page of bash (Special Parameters section) says:
>
>? expands to the exit status of the most
>recently executed foreground pipeline.
>
> Nevertheless, background commands also modify the
> value of this varia
> You're seeing the status from the creation of the background job (which is
> always 0), not from its completion.
Ah, I see.
Anyway, the behavior is not coherent with the manual page: in this
case, $? has the status from the creation of the background job,
that's not "the status of the most rece
On Fri, Sep 21, 2018 at 04:17:11PM +0200, Enrique Soriano wrote:
> > You're seeing the status from the creation of the background job (which is
> > always 0), not from its completion.
>
> Ah, I see.
>
> Anyway, the behavior is not coherent with the manual page: in this
> case, $? has the status f
On 9/21/18 11:17 AM, Eduardo A. Bustamante López wrote:
> On Fri, Sep 21, 2018 at 04:17:11PM +0200, Enrique Soriano wrote:
>>> You're seeing the status from the creation of the background job (which is
>>> always 0), not from its completion.
>>
>> Ah, I see.
>>
>> Anyway, the behavior is not cohere
On 9/21/18 7:49 AM, esori...@gsyc.urjc.es wrote:
> According to the manual:
>
> (I) Typing the suspend character (typically ^Z, Control-Z)
> while a process is running causes that process to be
> stopped and returns control to bash.
>
> (II) An OR list has the form
>
>
> The thing that creates the background job IS a foreground pipeline. It's a
> foreground pipeline that creates a background
> job, if that makes sense.
Sure. That's the mechanism to implement the background job.
The problem is that the user that reads the manual is dealing with the
"background"
On Fri, Sep 21, 2018 at 01:11:38PM +0200, Dr. Werner Fink wrote:
> Hi,
>
> with 4.3.48 the line
>
> T="";echo ">${T//*/ }<"
>
> leads to
>
> ><
>
> but with 4.4.23 the correct result is given back
>
> > <
>
> in the git repro I do not find any useful login entry for this
Check commit
Hello there,
we discovered a strange phenomenon in the project testssl.sh:
After opening a TCP socket with a fd (here: 5), when writing to it,
it seems that
printf -- "$data" >&5 2>/dev/null
does not do what it is intended. "$data" is a ClientHello like
'\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x
On 9/21/18 4:13 PM, dirk+b...@testssl.sh wrote:
>
> Hello there,
>
> we discovered a strange phenomenon in the project testssl.sh:
>
> After opening a TCP socket with a fd (here: 5), when writing to it,
> it seems that
>
> printf -- "$data" >&5 2>/dev/null
>
> does not do what it is intended.
dirk+b...@testssl.sh wrote:
> we discovered a strange phenomenon in the project testssl.sh:
You are doing something that is quite unusual. You are using a shell
script direction on a TCP socket. That isn't very common. More
typically one would use a C program instead. So it isn't surprising
th
14 matches
Mail list logo
