Front page | perl.perl5.porters |
Postings from November 2022
Re: FindBin.pm - Handle FIFOs / Named Pipes (PR #20472)
Thread Previous
From:
demerphq
Date:
November 5, 2022 08:42
Subject:
Re: FindBin.pm - Handle FIFOs / Named Pipes (PR #20472)
Message ID:
CANgJU+WuRSe5acYP=icUTweTypf5Lfw83kF7tzWyGgipR8bxRA@mail.gmail.com
On Fri, 4 Nov 2022 at 23:04, Dabrien 'Dabe' Murphy <dabe@dabe.com> wrote:
>
> On 11/1/22 8:11 PM, James E Keenan <notifications@github.com> wrote:
>
> https://github.com/Perl/perl5/pull/20472
>
> Whether we want FindBin to handle FIFOs and named pipes is something that really ought to be discussed first on the Perl5-Porters mailing list.
>
>
> Gladly! :-D
>
> So, this dies:
>
> bash% perl -MFindBin <(echo 'print "$FindBin::Bin\n"')
> Cannot find current script '/dev/fd/63' at FindBin.pm line 167.
> BEGIN failed--compilation aborted at FindBin.pm line 167.
>
> ... and rather than expecting downstream modules to wrap their imports in an `eval`:
>
> BEGIN { eval "use FindBin ()" }
> eval "FindBin::again()";
>
> ... this trivial change fixes the problem, and doesn't seem to introduce any apparent[*] regressions:
>
> --- a/dist/FindBin/lib/FindBin.pm
> +++ b/dist/FindBin/lib/FindBin.pm
> @@ -114,2 +114,2 @@ sub init
> - if($0 eq '-e' || $0 eq '-')
> + if($0 eq '-e' || $0 eq '-' || -p $0)
>
> [*] https://github.com/Perl/perl5/actions/runs/3374105629/
>
> I feel like the omission of `-p` was more of an oversight, rather than being expressly forbidden; it skews heavily toward the "Make The Hard Things Possible" end of the spectrum, and probably just nobody thought to try it before.
>
> IMHO, if `FindBin` can handle an *unnamed* pipe — STDIN — then it should treat a **NAMED** pipe/FIFO the same way, i.e., return the current directory.
>
> Having some of the regression tests depend on using bash as our shell will not fly. Perl builds on many operating systems, not all of which support bash and we use quite a few more shells than just bash
>
>
> Oh, I'll absolutely be the very first to admit that shelling out to `bash` was chock full of Code Smell; that's why I put a big `skip_all()` at the top, for systems/environments where bash isn't available...
>
> But for the vast percentage of systems where it **DOES** exist, it also seemed like the "Simplest Thing That Could Possibly Work",as well as being the most common situation to bite people in the wild... My guess is that anything "smarter" — e.g., calling `POSIX::mkfifo(mktemp, 0600)` and then `dup(2)`-ing that to `t/test.pl => runperl()`'s `\*STDIN`, or some such — would only introduce MORE portability headaches. «shrug»
>
> Anyway, I'm more than happy to jettison the whole `exec bash` nonsense! I just figured having at least *ONE* test for the Happy Path would be better than not providing any new `t/` tests at all...
I dont see any reason we wouldn't merge this provided it had proper
tests and the change didnt break any esoteric platforms we support.
Usually its not a problem making code handle a case it used to error
on, as in theory nobody would be using it there anyway. But we need to
be able to test that it doesn't cause trouble portably. I would rework
the tests while you wait to see what other replies come in. Findbin is
widely used, so we need to be a bit extra careful that changes to it
dont have weird ecosystem effects, but personally it doesn't seem like
something that would break anything.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous