Re: fuse

[lacsaP Patatetom]

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 :-)