On Mon, 2013-03-18 at 19:37 +0100, Bastian Bittorf wrote:
> * Joshua Judson Rosen <[email protected]> [18.03.2013 19:32]:
> > >>[ -e "$file" ]&& . "$file"
> > >>
> > >>not ok for you? my usecase was more a "speed" issue, because
> > >
> > >The only technical reason against that is the race condition if $file is
> > >deleted after the existence/read check.
> >
> > Yes. And there's no way to get around the shell aborting in that case.
>
> maybe something like:
>
> cp "$file" "/tmp/include_$$" || . "/tmp/include_$$"
>
> but this is really ugly.
ACK - and for that reason, I didn't mention it. Or - to avoid the
fork()+exec() - play around with "s=0; while read l; do s="$s $l"; done
< $file && eval $s" (which propably needs quoting ...) or the like ....
The more clean solution would be to invent a new command with same
semantics but with more robustness ....
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
