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
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.
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
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
> 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
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
>
>
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
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
> 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
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
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
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
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
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
14 matches
Mail list logo
