Skip to content
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

want way to change exit status from die #16589

Open
p5pRT opened this issue Jun 18, 2018 · 1 comment
Open

want way to change exit status from die #16589

p5pRT opened this issue Jun 18, 2018 · 1 comment

Comments

@p5pRT
Copy link

p5pRT commented Jun 18, 2018

Migrated from rt.perl.org#133287 (status was 'new')

Searchable as RT133287$

@p5pRT
Copy link
Author

p5pRT commented Jun 18, 2018

From @ijackson

Created by @ijackson

This is a bug report for perl from ijackson@​chiark.greened.org.uk,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------

The behaviour of die with respect to the whole perl interpreter's exit
status, as documented in perlfunc's entry for die, is often not
desirable. In particular, when trying to write a program which has
reliably predictable exit statuses depending on different error
conditions or outcomes. For example, consider reimplementing diff(1).

This can mostly be worked around with $SIG{__DIE__}.

But this is extremely awkard. And not only because of $SIG{__DIE__}'s
unfortunate and well idiosyncracies.

Even `use' can cause `die' with an unanticipated exit status. So
putting the $SIG{__DIE__} in an application module is not wise​: if the
application is misinstalled, `use My​::App​::SIGDIE' will cause use to
fail with ENOENT and the interpreter will exit status 2 !

So the application has to put something like this at the top of the
script before any of its other use's​:
  BEGIN { eval { require My​::Application​::SIGDIE }; if ($@​) { warn; exit -1 } }

Furthermore, there does not seem to be a sensible way to make sure the
exit status is correct even if the main script file cannot be opened
or read. One might think that this is unlikely, but possible
situations include​:
* 1 due to EPERM (perhaps due to security hardening arrangements)
* 2 due to ENOENT (perhaps the script file was removed during startup)
* 5 due to EIO (the storage device containing the script is failing)
etc.

I think the best way to solve this problem is to do at least this​:

0. Provide a new single-character command line option,
  perhaps -q, to change the $? value set by die, to 255.

A more comprehensive plan would be​:

1. Provide a new special variable $^? which is the fixed exit status
  set by die; if $^? is undef, then the existing algorithm is used

2. Provide a single-character command line option to set $^? to 255.

3. Change perl so that failure to open the script file any case causes
  perl to exit with status 255. After all, that is how the dynamic
  linker will handle failure to assemble the perl interpreter.

1+2 or 1+3 would be sufficient.

If relying on 2 rather than 3, we require a single-character option
because the option must be given in the #! line to have proper effect.
It is OK if the single-character option allows cuddling of a $^? value.

If combined with a fix to bug #30296, option 1 would have the side
effect of answer all those stackmumble questions "how do I make a die
exit with status ...". You could say
  local $^?=42; die "argh";

It would also be possible to solve this problem with a pragma, but
because pragmas cannot be conveniently specified on #! lines, option 3
(change to exit status on script read failure) will also be needed.

Perl Info

Flags:
    category=core
    severity=wishlist

Site configuration information for perl 5.24.1:

Configured by Debian Project at Tue Sep 12 16:37:26 UTC 2017.

Summary of my perl5 (revision 5 version 24 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=3.16.0, archname=x86_64-linux-gnu-thread-multi
    uname='linux localhost 3.16.0 #1 smp debian 3.16.0 x86_64 gnulinux '

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants