Re: Opening a `.HFS+ Private Directory Data'$'\r` folder messes up terminal prepended prompt

2020-02-08 Thread Lawrence Velázquez
> On Feb 7, 2020, at 9:06 AM, Greg Wooledge  wrote:
> 
> Meanwhile, I strongly advise you to rename this directory so that
> it doesn't end with a carriage return.

That would likely corrupt the volume, as $'/.HFS+ Private Directory Data\r'
is part of the HFS+ implementation of directory hard links.

https://wiki.sleuthkit.org/index.php?title=HFS#HFS.2B_Hard_Links

vq



Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'

2020-02-08 Thread Harald van Dijk

On 07/02/2020 02:41, Robert Elz wrote:

 Date:Thu, 6 Feb 2020 16:12:06 +
 From:Martijn Dekker 
 Message-ID:  <10e3756b-5e8f-ba00-df0d-b36c93fa2...@inlv.org>

   | NetBSD sh behaves differently. NetBSD 8.1 sh (as installed on sdf.org
   | and sdf-eu.org) seem to act completely normally, but NetBSD 9.0rc2 sh
   | (on my VirtualBox test VM) segfaults. Output on NetBSD 9.0rc2:

I have updated my opinion on that, I think it is "don't have the bug",
though it is possible a blocked SIGCHLD acts differently on NetBSD than
on other systems.   On NetBSD it seems to affect nothing (the shell does
not rely upon receiving SIGCHLD so not getting it is irrelevant) and
the wait code when given an arg (as your script did) would always wait
until that process exited, and return as soon as it did.


I think you're right that this isn't SIGCHLD behaving differently on 
NetBSD, it's that NetBSD sh does not have the same problem the other 
ash-based shells do. The problem is with sigsuspend, which in dash looks 
like:



sigblockall(&oldmask);

while (!gotsigchld && !pending_sig)
sigsuspend(&oldmask);

sigclearmask();




This clearly cannot work when oldmask blocks SIGCHLD.

NetBSD sh does not use sigsuspend here, so avoids that problem.

I changed gwsh to call sigclearmask() on shell startup, but plan to 
check whether this loop is really necessary at some later time. It was 
added to dash to fix a race condition, where that race condition was 
apparently introduced by a fix for another race condition. If NetBSD sh 
manages to avoid this pattern, and assuming NetBSD sh is not still 
susceptible to one of those race conditions, the fix for it in the other 
shells would seem to be more complicated than necessary, and simplifying 
things would be good.


Cheers,
Harald van Dijk



Lack of documentation about mapfile callback

2020-02-08 Thread Léa Gris
man bash.1
> When callback is evaluated, it is supplied the index of the next 
> array element to be assigned and the line to be assigned to that 
> element as additional arguments. callback is evaluated after the
> line is read but before the array element is assigned.

I can not find real-life implementation example of the mapfile callback
that fit the implied scenario of this behavior of invoking the callback
before the last array entry is assigned.

What I figured out by experimentation, is that while the last element is
not assigned to MAPFILE as seen from the callback context, the
assignment is effective after the callback returns.

Example:

- BEGIN BASH
#!/usr/bin/env bash

callback() {
  echo "Entering Callback"
  printf 'Next index is: %d\n' $1
  printf 'Next entry is: %q\n' "$2"
  printf 'MAPFILE size: %d\n' "${#MAPFILE[@]}"
  typeset -p MAPFILE
  echo "Exiting Callback"
}

mapfile -t -C callback -c 3 <<'EOF'
Entry0
Entry1
Entry2
Entry3
Entry4
Entry5
Entry6
Entry7
Entry8
EOF
- END BASH

And then the output:
- BEGIN OUTPUT
Entering Callback
Next index is: 2
Next entry is: Entry2
MAPFILE size: 2
declare -a MAPFILE=([0]="Entry0" [1]="Entry1")
Exiting Callback
Entering Callback
Next index is: 5
Next entry is: Entry5
MAPFILE size: 5
declare -a MAPFILE=([0]="Entry0" [1]="Entry1" [2]="Entry2" [3]="Entry3"
[4]="Entry4")
Exiting Callback
Entering Callback
Next index is: 8
Next entry is: Entry8
MAPFILE size: 8
declare -a MAPFILE=([0]="Entry0" [1]="Entry1" [2]="Entry2" [3]="Entry3"
[4]="Entry4" [5]="Entry5" [6]="Entry6" [7]="Entry7")
Exiting Callback
- END OUTPUT


It reveals the weirdness of running the callback before the last
assignment from the quantum.
First call to callback has a MAPFILE with 2 entries, while the next two
have 3 entries.
There must be a reason or an intended scenario for this implementation,
but with so few documentation and no real-world usage example, it is
unclear to me.

-- 
Lea Gris



Re: Lack of documentation about mapfile callback

2020-02-08 Thread Chet Ramey
On 2/8/20 9:04 PM, Léa Gris wrote:
> man bash.1
>> When callback is evaluated, it is supplied the index of the next 
>> array element to be assigned and the line to be assigned to that 
>> element as additional arguments. callback is evaluated after the
>> line is read but before the array element is assigned.
> 
> I can not find real-life implementation example of the mapfile callback
> that fit the implied scenario of this behavior of invoking the callback
> before the last array entry is assigned.

The mapfile builtin originally came in to support the bash debugger; I
assume that is a good enough example.

-- 
``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/