New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: file handle duping in the Bourne shell tradition #13146
Comments
From perl-diddler@tlinx.orgCreated by perl-diddler@tlinx.orgI noted the 'open' manpage mentions using >& in the bourne Could the open call be made to recognize integer file descriptors
Perl Info
|
From @ikegamiWhy would you want to redirect a descriptor for which you don't have a For descriptors for which you do have a handle, you can do the following: $ perl -E'warn "foo\n";' >/dev/null $ perl -E'open(STDERR, ">&=", 1) or die $!; warn "foo\n";' >/dev/null $ |
The RT System itself - Status changed from 'new' to 'open' |
From perl-diddler@tlinx.orgOn Fri Aug 02 06:20:32 2013, ikegami@adaelis.com wrote:
I know there are alternate ways that are more complex to do what I ask, or ($errs, "2>", \$errvar) && ..runcmd... hoping to pick up stderr Sure, there's likely more complex ways to do it, but having the manpage Note, in shell if you really want input from file "2", you need to |
From @rjbs* Linda Walsh <perlbug-followup@perl.org> [2013-08-02T07:29:13]
I don't think this will happen.
What about if, instead of removing the bit about duping, we add a bit reminding -- |
From @ikegamiOn Fri, Aug 2, 2013 at 3:53 PM, Linda Walsh via RT <
Maybe, but why would you mentioned those instead of the simpler one that
I've already said 2>&1 doesn't make much sense. You're actually suggesting open(fileno($HANDLE).">&1") which can currently be written as open(STDERR, ">&1") in addition to the more consistent open(STDERR, ">&", 1) |
From perl-diddler@tlinx.orgOn Fri Aug 02 15:33:02 2013, perl.p5p@rjbs.manxome.org wrote:
Now that's depressing. I was just thinking about perl's history and
Um... you mean right in the section where it says the EXPR after >& is There are at least a few spots that refer to it working with file |
From perl-diddler@tlinx.orgOn Fri Aug 02 20:03:06 2013, ikegami@adaelis.com wrote:
I can dup 2 to three with 3>&2, what the perl syntax for that? The point is perl takes fd's on the right -- why not on the left? If I did open(or maybe exec?) (undef, "2>&1") perl would redirect Ideally, I could do something like (undef, "2>&", \$var) and get It's really boiling down to conciseness, balance, and form... having it |
From @rjbs* Linda Walsh via RT <perlbug-followup@perl.org> [2013-08-02T23:13:33]
Perl not making one particular change to the behavior of the already very
I mean that we can clarify the way it does work by adding a clear piece of -- |
From @LeontOn Fri, Aug 2, 2013 at 1:29 PM, Linda Walsh <perlbug-followup@perl.org> wrote:
use POSIX 'dup2' Leon |
From perl-diddler@tlinx.orgOn Fri Aug 02 20:35:51 2013, perl.p5p@rjbs.manxome.org wrote:
In this case, it was increasing the regularity of the syntax to approach I think that was a major selling point, back when perl was young, is
Well, it's just confusing since in some places it says shell is I tried open(my fd, "cmd 2>&1 |") to get both std err and out on Obviously fixing the manpage makes perl legalistically correct, but does I noticed that no one answer my more complex Q's save 2->3, dup2to1 FH, then there was my Q about how well the read/write to scalars integrated I asked for an easier way to include modules in the same file and be Before that I asked for why sprint and printf had to have different Before that-- have UTF8 default to reading local like most other desktop All the while in having these ideas, made to feel like a pariah and How about this one -- not require sigils where they are unnecessary or anyway... this one -- wishlist that open supported fd's on both sides of |
From zefram@fysh.orgThe requested feature wouldn't make sense. open() consistently uses -zefram |
@iabyn - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#119127 (status was 'rejected')
Searchable as RT119127$
The text was updated successfully, but these errors were encountered: