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

#!/usr/bin/perl -CO #7792

Closed
p5pRT opened this issue Feb 7, 2005 · 10 comments
Closed

#!/usr/bin/perl -CO #7792

p5pRT opened this issue Feb 7, 2005 · 10 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 7, 2005

Migrated from rt.perl.org#34087 (status was 'resolved')

Searchable as RT34087$

@p5pRT
Copy link
Author

p5pRT commented Feb 7, 2005

From @Abigail

Created by @Abigail

"man perlrun" says​:

  The #! line is always examined for switches as the line is
  being parsed. Thus, if you're on a machine that allows
  only one argument with the #! line, or worse, doesn't even
  recognize the #! line, you still can get consistent switch
  behavior regardless of how Perl was invoked, even if -x
  was used to find the beginning of the program.

It also says later on that "-CO" tells perl to assume that STDOUT to be
in UTF-8.

However, given the following program​:

  $ cat utf
  #!/usr/bin/perl -CO
  print "\x{256}\n";
  __END__

I would expect

  $ perl utf > /dev/null

to be silent. But if I run it, it says​:

  Wide character in print at utf line 2.

Now, I understand that this is probably caused by STDOUT already setup
before "-CO" is processed, but I still think it's a bug.

Preferably, using -CO on the she-bang line should silence the warning, and
if not, the documentation should document this case.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.6:

Configured by abigail at Wed Dec  8 23:38:06 CET 2004.

Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
  Platform:
    osname=linux, osvers=2.4.18-bf2.4, archname=i686-linux-64int-ld
    uname='linux alexandra 2.4.18-bf2.4 #1 son apr 14 09:53:28 cest 2002 i686 unknown '
    config_args='-des -Dusemorebits -Uversiononly -Dmydomain=.abigail.nl -Dcf_email=abigail@abigail.nl -Dperladmin=abigail@abigail.nl -Doptimize=-g -Dcc=gcc -Dprefix=/opt/perl'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='3.0.4', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    no-syntax-warnings
    defined-or


@INC for perl v5.8.6:
    /home/abigail/Perl
    /opt/perl/lib/5.8.6/i686-linux-64int-ld
    /opt/perl/lib/5.8.6
    /opt/perl/lib/site_perl/5.8.6/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.6
    /opt/perl/lib/site_perl/5.8.5/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.5
    /opt/perl/lib/site_perl/5.8.4/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.4
    /opt/perl/lib/site_perl/5.8.3/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.3
    /opt/perl/lib/site_perl/5.8.2/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.2
    /opt/perl/lib/site_perl/5.8.1/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.1
    /opt/perl/lib/site_perl/5.8.0/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.0
    /opt/perl/lib/site_perl
    .


Environment for perl v5.8.6:
    HOME=/home/abigail
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/abigail/Lib:/usr/local/lib:/usr/lib:/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/home/abigail/Bin:/opt/perl/bin:/usr/local/bin:/usr/local/X11/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/games:/usr/share/texmf/bin:/opt/Acrobat/bin:/opt/java/blackdown/j2sdk1.3.1/bin:/usr/local/games/bin
    PERL5LIB=/home/abigail/Perl
    PERLDIR=/opt/perl
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2005

From @Tux

On 7 Feb 2005 22​:45​:00 -0000, "abigail@​abigail.nl (via RT)"
<perlbug-followup@​perl.org> wrote​:

"man perlrun" says​:

   The \#\! line is always examined for switches as the line is
   being parsed\.  Thus\, if you're on a machine that allows
   only one argument with the \#\! line\, or worse\, doesn't even
   recognize the \#\! line\, you still can get consistent switch
   behavior regardless of how Perl was invoked\, even if \-x
   was used to find the beginning of the program\.

It also says later on that "-CO" tells perl to assume that STDOUT to be
in UTF-8.

However, given the following program​:

$ cat utf
\#\!/usr/bin/perl \-CO
print "\\x\{256\}\\n";
\_\_END\_\_

I would expect

$ perl utf > /dev/null

to be silent. But if I run it, it says​:

Wide character in print at utf line 2\.

Now, I understand that this is probably caused by STDOUT already setup
before "-CO" is processed, but I still think it's a bug.

Preferably, using -CO on the she-bang line should silence the warning, and
if not, the documentation should document this case.

I can fully confirm this behaviour, and would suggest to forbid -C on shebang
line, or give a warning if shebang finds -C

FWIW using -Co instead of -CO (for all output streams instead of just STDOUT)
does not alter the behaviour.

binmode STDOUT, "​:utf8";

would be the `script' equivalent of the command line option -CO

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.3, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
  AIX 4.3, SuSE 9.0 pro 2.4.21 & Win2k. http​://www.cmve.net/~merijn
Smoking perl​: smokers@​perl.org, perl QA​: http​://qa.perl.org
  reports to​: smokers-reports@​perl.org, perl-qa@​perl.org

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2005

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Feb 9, 2005

From perl@nevcal.com

On approximately 2/8/2005 5​:05 AM, came the following characters from
the keyboard of H.Merijn Brand​:

On 7 Feb 2005 22​:45​:00 -0000, "abigail@​abigail.nl (via RT)"
<perlbug-followup@​perl.org> wrote​:

"man perlrun" says​:

  The \#\! line is always examined for switches as the line is
  being parsed\.  Thus\, if you're on a machine that allows
  only one argument with the \#\! line\, or worse\, doesn't even
  recognize the \#\! line\, you still can get consistent switch
  behavior regardless of how Perl was invoked\, even if \-x
  was used to find the beginning of the program\.

It also says later on that "-CO" tells perl to assume that STDOUT to be
in UTF-8.

However, given the following program​:

$ cat utf
#!/usr/bin/perl -CO
print "\x{256}\n";
__END__

I would expect

$ perl utf > /dev/null

to be silent. But if I run it, it says​:

Wide character in print at utf line 2.

Now, I understand that this is probably caused by STDOUT already setup
before "-CO" is processed, but I still think it's a bug.

Preferably, using -CO on the she-bang line should silence the warning, and
if not, the documentation should document this case.

I can fully confirm this behaviour, and would suggest to forbid -C on shebang
line, or give a warning if shebang finds -C

FWIW using -Co instead of -CO (for all output streams instead of just STDOUT)
does not alter the behaviour.

binmode STDOUT, "​:utf8";

would be the `script' equivalent of the command line option -CO

So if there is an easy 'script' equivalent to the option, why shouldn't
one DWIM the option, allowing it to work on the shebang would be much
more DWIMmy. If there was a technical impossibility to make it function
properly, I'd agree that a warning when finding the option on the
shebang line would be appropriate.

--
Glenn -- http​://nevcal.com/

Having identified a vast realm of ignorance, Wolfram is saying that much
of this realm lies forever outside the light cone of human knowledge.
  -- Michael Swaine, Dr Dobbs Journal, Sept 2002

@p5pRT
Copy link
Author

p5pRT commented Feb 9, 2005

From @Abigail

On Tue, Feb 08, 2005 at 01​:05​:49PM -0000, H. Merijn Brand via RT wrote​:

I can fully confirm this behaviour, and would suggest to forbid -C on shebang
line, or give a warning if shebang finds -C

Is that because you think -C shouldn't be able to be given on the shebang
line, or because that's the easiest way to fix this?

Abigail

@p5pRT
Copy link
Author

p5pRT commented Feb 9, 2005

From @Tux

On Wed, 9 Feb 2005 01​:02​:35 +0100, Abigail <abigail@​abigail.nl> wrote​:

On Tue, Feb 08, 2005 at 01​:05​:49PM -0000, H. Merijn Brand via RT wrote​:

I can fully confirm this behaviour, and would suggest to forbid -C on
shebang line, or give a warning if shebang finds -C

Is that because you think -C shouldn't be able to be given on the shebang
line, or because that's the easiest way to fix this?

The first. Of course.

The scripting way of doing it with binmode is so easy, well documented, and
self-documenting, that -C on the shebang is only obfuscating

shebang command line options are not there for clarity, but for functionality
I also thing that in a *script*, -Mmodule should not be allowed on the
shebang, use module; is the way to go.

For (short) scripts, maybe the only useful options for the shebang line are
-a, -F, -i, -n/-p, -s, -T, -U, -w, and -W
Only providing more obfuscation or completely useless are -c, -C, -d, -e, -h
(haha), -I, -m, -M, -P, -S, -u, -v, -V, and -x
No firm opinion on the others

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.3, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
  AIX 4.3, SuSE 9.0 pro 2.4.21 & Win2k. http​://www.cmve.net/~merijn
Smoking perl​: smokers@​perl.org, perl QA​: http​://qa.perl.org
  reports to​: smokers-reports@​perl.org, perl-qa@​perl.org

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2005

From @rgs

H.Merijn Brand wrote​:

I can fully confirm this behaviour, and would suggest to forbid -C on shebang
line, or give a warning if shebang finds -C

Agreed ; forbidden as change #24070 in blead.

@p5pRT p5pRT closed this as completed Mar 22, 2005
@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2005

@rgs - Status changed from 'open' to 'resolved'

@p5pRT
Copy link
Author

p5pRT commented Mar 22, 2005

From @Abigail

On Tue, Mar 22, 2005 at 04​:19​:51PM +0100, Rafael Garcia-Suarez wrote​:

H.Merijn Brand wrote​:

I can fully confirm this behaviour, and would suggest to forbid -C on shebang
line, or give a warning if shebang finds -C

Agreed ; forbidden as change #24070 in blead.

:-(

Abigail

@p5pRT
Copy link
Author

p5pRT commented May 2, 2009

From Markus.Kuhn@cl.cam.ac.uk

I used to be able to write in Perl 5.8.1 simply

  #!/usr/bin/perl -C

at the top of the script to ensure that all I/O used by default the
encoding defined by the locale setting (LC_ALL or LC_CTYPE or LANG).

How do I do this now after the above "fix" broke this very useful
functionality (which basically preserves the default behavior of Perl
5.8.0)? Adding -C after the "hash bang" was a *very* convenient solution
and worked fine on systems where the kernel interpreted the hash bang.
It was offered after the - for many applications very desirable -
locale-dependent I/O behavior of Perl 5.8.0 was removed due to backwards
compatibility fears. You have now removed the simple fix that we were
then promised we could use from 5.8.1 to get the I/O charset defined by
the locale.

I guess the alternative would look as clumsy as

binmode STDIN, "​:locale";
binmode STDOUT, "​:locale";
binmode STDERR, "​:locale";

but sadly "man perluniintro" says that :locale does not work with
binmode(). :-(((

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

1 participant