help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fuse


From: lacsaP Patatetom
Subject: Re: fuse
Date: Thu, 6 Apr 2023 16:28:41 +0200

Le jeu. 6 avr. 2023 à 15:30, Greg Wooledge <greg@wooledge.org> a écrit :
>
> On Thu, Apr 06, 2023 at 03:13:53PM +0200, lacsaP Patatetom wrote:
> > 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.
>
> Yeah, OK.  You're opening file descriptor 10, which points to the
> same place as FD 1, which is the pipe that gets read by the command
> substitution in the "master" script.
>
> This FD is inherited by mount, and then, I presume, by the long-running
> mount child process.  (You could verify that by looking in /proc/$pid/fd
> where $pid is the PID of that mount child, but for now let's assume
> it's true.)
>
> Since the mount child is still running, and still has FD 10 open (which
> points to the pipe), the pipe never reaches an End Of File state, and
> the process substitution continues to wait for more input from that pipe.
> The process substitution will "block" until that pipe reaches EOF, by
> closing all of the FDs that point to it.
>
> The obvious fix here would be to stop doing that exec 10>&1 dance, and
> simply redirect the output of the two commands in between mkdir and mount.
> You may also need to redirect the output of mount -- I'm not sure about
> that.
>
> If you don't want to do that, then the second most obvious fix would
> be to move the "exec 1>&10 10>&-" line up above mount, and once again,
> you may also need to redirect mount's output.
>
> The third most obvious fix would be to close FD 10 when you invoke mount,
> by adding a 10>&- redirection on the mount command.  And, yes, you may
> also need to redirect stdout.
>

I thought and said it was not a long-running process, but in fact it
is, which explains why the master script does not get the hand :-(

here is the FDs of the mount.extfat process :
lrwx------ 1 root root 64  6 avril 13:52 0 -> /dev/null
lrwx------ 1 root root 64  6 avril 13:52 1 -> /dev/null
l-wx------ 1 root root 64  6 avril 13:52 10 -> pipe:[15196]
lrwx------ 1 root root 64  6 avril 13:52 2 -> /dev/null
lr-x------ 1 root root 64  6 avril 13:52 3 -> /dev/sdc1
lrwx------ 1 root root 64  6 avril 13:52 4 -> /dev/fuse
and FD10 is linked to the pipe.

thanks for fixes Greg.

regards, lacsaP.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]