Re: fuse

[lacsaP Patatetom]

Le jeu. 6 avr. 2023 à 14:15, lacsaP Patatetom <patatetom@gmail.com> a écrit :
>
> Le jeu. 6 avr. 2023 à 14:04, lacsaP Patatetom <patatetom@gmail.com> a écrit :
> >
> > Le jeu. 6 avr. 2023 à 13:40, Greg Wooledge <greg@wooledge.org> a écrit :
> > >
> > > On Thu, Apr 06, 2023 at 01:33:03PM +0200, lacsaP Patatetom wrote:
> > > > I have a bash script that calls another bash script like this :
> > > > device=$( other.script ) ||
> > > >   exit 1
> > > >
> > > > this other/sub script mounts a Windows partition and returns its path :
> > > > mount /dev/sdXy /mnt &&
> > > >   echo debug >> /dev/stderr &&
> > > >     echo /dev/sdXy ||
> > > >   exit 1
> > > >
> > > > no problem when this partition is of FAT type.
> > > > on the other hand, when this partition is of type exFAT or NTFS, the
> > > > master script stops despite the display of the "debug".
> > > > in these two cases, it is FUSE which takes part in the mounting of the
> > > > partition : I thus suppose that it is at this level that the blocking
> > > > intervenes...
> > >
> > > You used the word "stops".  And then you used the word "blocking".  So,
> > > you DON'T mean that the script crashes, right?  You mean that the script
> > > "hangs" or "sits there doing nothing"?
> > >
> >
> > no, there is no crash.
> > yes, the script hangs or sits there doing nothing if you prefer.
> >
> > > > would someone have an explanation or encountered this problem ?
> > >
> > > I would guess that the mount command produces a long-running child
> > > process which inherits stdout from mount.  Since you didn't redirect
> > > stdout anywhere, it's still attached to the pipe which is attached to
> > > the command substitution in the caller.
> > >
> >
> > this is not a long child run.
> >
> > > If you redirect mount's output to /dev/null (or to a log file), does
> > > that change anything?
> > >
> >
> > adding `mount ... &>/dev/null` in sub script does not solve the problem.
> > when the master script is in "standby mode", `ps ax` played in another
> > terminal shows the presence of the command `/usr/bin/mount..exfat ...`
> > : if I manually kill this one, the master script resumes its
> > execution.
> >
> > > Also, just for the record, ">>/dev/stderr" is a very strange way to
> > > write ">&2".
> > >
> >
> > yes :-)
>
> the sub script use the "generic" `mount` command.
> the `ps ax` shows `/usr/bin/mount.exfat` when the partition is of type
> exFAT and `/usr/bin/mount.ntfs` when it is of type NTFS.
> no problem when the partition is of type FAT(32) (and no trace of the
> mount command among the processes).

after careful rereading of the sub script, the following command
appears to be the cause of the (surprising4me) problem : `exec 10>&1
&& exec >/dev/null`

here are the two scripts in a basic/simplified way :

8<-- /tmp/master --------
#!/usr/bin/bash
device=$( /tmp/sub /dev/sda1 ) || exit 1
echo "$device"
8<--------------------------

8<-- /tmp/sub ------------
#/bin/bash
exec 10>&1 && exec >/dev/null
mkdir -p /sub
echo "command that writes to /dev/fd/1 : don't want this data/text"
echo "another command that writes to /dev/fd/1 : don't want this data/text"
[ "$1" ] && [ -b "$1" ] && mount "$1" /sub || exit 1
exec >&10 10>&-
echo "$1 mounted" >&2
echo "$1"
8<-------------------------

the `exec` command lines are supposed to capture/delete/clear anything
that might be sent to /dev/fd/1 before the final `echo "$1"`.

if I run `/tmp/master` with the `exec` command lines present,
`/dev/sda1 mounted` is displayed, but the master script does not get
control.

on the other hand, if I comment out the `exec` command lines, the
master script does get control but displays things I don't want.

again, this only happens if it is an exFAT/NTFS partition that finally
calls FUSE.