[31913] in Perl-Users-Digest
Perl-Users Digest, Issue: 3176 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 15 18:09:24 2010
Date: Fri, 15 Oct 2010 15:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 15 Oct 2010 Volume: 11 Number: 3176
Today's topics:
Re: FAQ 4.38 Why don't my <<HERE documents work? <john@example.invalid>
interesting "feature": \%$x == $x <tzz@lifelogs.com>
Re: interesting "feature": \%$x == $x <uri@StemSystems.com>
Re: interesting "feature": \%$x == $x <tzz@lifelogs.com>
Re: interesting "feature": \%$x == $x <ben@morrow.me.uk>
Re: interesting "feature": \%$x == $x <tzz@lifelogs.com>
Re: simple problem using GD <marc.girod@gmail.com>
where to install cpan modules <john@example.invalid>
Re: why does this happen? <Huge@nowhere.much.invalid>
Re: why does this happen? <sherm.pendley@gmail.com>
Re: why does this happen? <Huge@nowhere.much.invalid>
Re: why does this happen? <whynot@pozharski.name>
Re: why does this happen? <hjp-usenet2@hjp.at>
Re: why does this happen? <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 15 Oct 2010 15:18:58 -0600
From: John Smith <john@example.invalid>
Subject: Re: FAQ 4.38 Why don't my <<HERE documents work?
Message-Id: <a6KdnZtvVrTeWCXRnZ2dnUVZ5uKdnZ2d@giganews.com>
sln@netherlands.com wrote:
> On Sat, 09 Oct 2010 21:08:33 -0600, John Smith <john@example.invalid> wrote:
>
>> PerlFAQ Server wrote:
>>
>>> A nice general-purpose fixer-upper function for indented here documents
>>> follows. It expects to be called with a here document as its argument.
>>> It looks to see whether each line begins with a common substring, and if
>>> so, strips that substring off. Otherwise, it takes the amount of leading
>>> whitespace found on the first line and removes that much off each
>>> subsequent line.
>> This faq is dead on what I'm studying in particular tonight, so I
>> thought I would give this a whirl. I haven't quoted much of the
>> original post for the sake of brevity. I did copy the fix() function in
>> without changes. I think I'm calling it correctly too, but I think I've
>> got a message coming out on stderr and output that doesn't behave:
>>
>> $ perl l5.pl
>> ...we will have peace, when you and all your works have
>> perished--and the works of your dark master to whom you
>> would deliver us. You are a liar, Saruman, and a corrupter
>> of men's hearts. --Theoden in /usr/src/perl/taint.c
>>
>> ...we will have peace, when you and all your works have
>> perished--and the works of your dark master to whom you
>> would deliver us. You are a liar, Saruman, and a corrupter
>> of men's hearts.
>> --Theoden in /usr/src/perl/taint.
>> Here's a line
>> and here's another.
> =======================
>
>> Use of uninitialized value $leader in regexp compilation at l5.pl line 30.
>
> =======================
> This message?
>
>> usr/local/
>> usr/local/doc
>> usr
>> $ cat l5.pl
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>>
>> (my $quote = <<'FINIS') =~ s/^\s+//gm;
>> ...we will have peace, when you and all your works have
>> perished--and the works of your dark master to whom you
>> would deliver us. You are a liar, Saruman, and a corrupter
>> of men's hearts. --Theoden in /usr/src/perl/taint.c
>> FINIS
>> print $quote;
>>
>> ($quote = <<'FINISH') =~ s/\s+--/\n--/;
>>
>> ...we will have peace, when you and all your works have
>> perished--and the works of your dark master to whom you
>> would deliver us. You are a liar, Saruman, and a corrupter
>> of men's hearts. --Theoden in /usr/src/perl/taint.
>> FINISH
>> print $quote;
>>
>> sub fix {
>> local $_ = shift;
>> my ($white, $leader); # common whitespace and common
>> leading string
>> if (/^\s*(?:([^\w\s]+)(\s*).*\n)(?:\s*\g1\g2?.*\n)+$/) {
>> ($white, $leader) = ($2, quotemeta($1));
>> } else {
>> ($white, $leader) = (/^(\s+)/, '');
> ^^^^^^^^^^^^^^
> This is a list, the first item is a regex with capture group(s),
> the second item is the empty string ''.
> So the capture group(s) will be flattend out and the '' added
> at the end.
>
> The first item, the regex, is interpreted in list context.
> In this context, the regex must susceed before the capture group(s)
> data(s) are added to the list.
>
> But IF the regex failed, that which is creating the list, interprets
> the element as just another empty list ().
>
> So what happenes in the case that the list is expecting another
> list from the regex (it is in this case), is that an empty list ()
> is inserted. The effect of embedded an empty list in another list is
> that nothing is inserted. Everything to the right shifts left one position
> in the list.
>
> So, when the regex failed, ($white, $leader) = (/^(\s+)/, '');
> was interpreted as
> ($white, $leader) = ( (), 'I am leader' );
> or really
> ($white, $leader) = ( 'I am leader' );
>
> $white now equals 'I am leader' (the '' really)
> $leader now equals undef;
>
> ---------------
>
> Its really, really bad to insert regex's into lists this way.
> The empty list () will disturb the order.
> And there is actually two problems, one is an undef message because
> of the list not being in the expected order, and an element being
> undef that is not being checked.
>
> You can overcome the element shift by doing this:
>
> ($white, $leader) = (/^(\s+)/ ? $1 : '', '');
>
> The defined'ness of $1 is a factor too if capture groups are inserted
> with alternations like:
>
> (/^(\s+)|(\s*)/ ? .. : .., '')
>
> But thats another issue. If it gets that complex, it should be moved out
> from within the list creation syntax, and assignd a variable to be inserted
> in the list.
>
> Some would just fix up the regular expression (\s*), but it is still a bad idea,
> imo, to do it from within list creation.
Thanks for your comment, sjouke, it does me all the good to hear someone
"talk through" execution.
I think that what you say makes a good case for altering $fix slightly,
so that the empty string created by data that don't need to be "$fixed"
doesn't cause an element shift.
You suggest 2 different ways, the latter being what Tad suggested. As a
Frequent User of the FAQ's, I would suggest a change in the script or
of its description.
--
John Smith
------------------------------
Date: Fri, 15 Oct 2010 11:44:18 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: interesting "feature": \%$x == $x
Message-Id: <87pqvbqucd.fsf@lifelogs.com>
perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
-> HASH(0xfc7d48) == HASH(0xfc7d48)
I wonder if this is a bug or a feature.
Ted
------------------------------
Date: Fri, 15 Oct 2010 12:58:32 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: interesting "feature": \%$x == $x
Message-Id: <87k4lj5r5z.fsf@quad.sysarch.com>
>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
-> HASH(0xfc7d48) == HASH(0xfc7d48)
perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
%s == %s
HASH(0x1271df0)HASH(0x1271df0)
did you mean printf?
TZ> I wonder if this is a bug or a feature.
hard to tell as you don't say what you think went wrong.
if it was printf you meant, it makes perfect sense. you dereferenced $x
and took a reference. it should give the same address. it isn't copying
the hash and allocating a new one like an anon hash would. these are
very different:
\%$x
{%$x}
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 15 Oct 2010 12:04:41 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: interesting "feature": \%$x == $x
Message-Id: <87lj5zqtee.fsf@lifelogs.com>
On Fri, 15 Oct 2010 12:58:32 -0400 "Uri Guttman" <uri@StemSystems.com> wrote:
>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
-> HASH(0xfc7d48) == HASH(0xfc7d48)
UG> perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
UG> %s == %s
UG> HASH(0x1271df0)HASH(0x1271df0)
UG> did you mean printf?
Yes, copy&pasted the wrong command line.
TZ> I wonder if this is a bug or a feature.
UG> hard to tell as you don't say what you think went wrong.
UG> if it was printf you meant, it makes perfect sense. you dereferenced $x
UG> and took a reference. it should give the same address. it isn't copying
UG> the hash and allocating a new one like an anon hash would. these are
UG> very different:
UG> \%$x
I always thought that chain would create a new reference to the same
data. Now that I think about it, it's just my confusion because
normally I do "%copy = %$x"
(and a lesson for writing good code: don't try to be cute :)
Ted
------------------------------
Date: Fri, 15 Oct 2010 18:36:09 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: interesting "feature": \%$x == $x
Message-Id: <91gmo7-cft1.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On Fri, 15 Oct 2010 12:58:32 -0400 "Uri Guttman" <uri@StemSystems.com> wrote:
>
> >>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
> TZ> perl -e'$x = {}; print "%s == %s\n", $x, \%$x'
[printf]
>
> -> HASH(0xfc7d48) == HASH(0xfc7d48)
>
>
> UG> if it was printf you meant, it makes perfect sense. you dereferenced $x
> UG> and took a reference. it should give the same address. it isn't copying
> UG> the hash and allocating a new one like an anon hash would. these are
> UG> very different:
>
> UG> \%$x
>
> I always thought that chain would create a new reference to the same
> data.
It does. The numbers in the stringification of the ref are related to
the referent, not the ref itself. See:
~% perl -MDevel::Peek -e'my $x = {}; warn $x; Dump $x; Dump \%$x'
HASH(0x8103a34) at -e line 1.
SV = IV(0x81172f0) at 0x81172f4
^^^^^^^^^ this part is different
REFCNT = 1
FLAGS = (PADMY,ROK)
RV = 0x8103a34
^^^^^^^^^ this part is the same
SV = PVHV(0x810a284) at 0x8103a34
^^^^^^^^^ so is this
REFCNT = 1
<snip>
SV = IV(0x8103bfc) at 0x8103c00
^^^^^^^^^
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x8103a34
^^^^^^^^^
SV = PVHV(0x810a284) at 0x8103a34
^^^^^^^^^
REFCNT = 2
<snip>
> Now that I think about it, it's just my confusion because
> normally I do "%copy = %$x"
If you want a ref to a copy of the hash, you need
my $copy = {%$x};
Ben
------------------------------
Date: Fri, 15 Oct 2010 12:57:18 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: interesting "feature": \%$x == $x
Message-Id: <87ocavpce9.fsf@lifelogs.com>
On Fri, 15 Oct 2010 18:36:09 +0100 Ben Morrow <ben@morrow.me.uk> wrote:
BM> The numbers in the stringification of the ref are related to the
BM> referent, not the ref itself.
Oh, I see. It all makes sense now. So I was making a new reference to
the same data structure.
BM> If you want a ref to a copy of the hash, you need
BM> my $copy = {%$x};
Yeah, no more "hey I can save a byte" cuteness for me.
Ted
------------------------------
Date: Fri, 15 Oct 2010 02:30:44 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: simple problem using GD
Message-Id: <bbcc4e8e-6d5f-4821-9ee9-f2e250b7ea82@i21g2000yqg.googlegroups.com>
On Oct 14, 8:12=A0pm, "juliani.m...@gmail.com" <juliani.m...@gmail.com>
wrote:
> Any suggestion?
- don't quote the variable.#
- try with other constant values:
$newimg->string(gdSmallFont,3,3,"Data Source: User submitted",$red);
$newimg->string(gdSmallFont,3,5,"Data Source: User submitted",$red);
$newimg->string(gdSmallFont,3,10,"Data Source: User submitted",$red);
$newimg->string(gdSmallFont,3,20,"Data Source: User submitted",$red);
- and with setting the variable to 2:
$ftop=3D 2;
$newimg->string(gdSmallFont,3,$ftop,"Data Source: User submitted",
$red);
Marc
------------------------------
Date: Fri, 15 Oct 2010 15:35:21 -0600
From: John Smith <john@example.invalid>
Subject: where to install cpan modules
Message-Id: <osadnSjSzsuHVCXRnZ2dnUVZ5vKdnZ2d@giganews.com>
I've installed CPAN modules before, but that was back when I was a
windows user and had an activestate install, which was, btw, an
excellent software product, given the platform it runs on.
It was always important to put modules in the right place. I'm trying
to figure out what that place is, and in the CPAN faqs, is says I can
divine it from the following command:
# perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=linux, osvers=2.6.24-23-server,
archname=i486-linux-gnu-thread-multi
uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14 utc
2009 i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.10.0
-Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio
-Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib
-Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing
-pipe -I/usr/local/include'
ccversion='', gccversion='4.3.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/lib64
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.9.so, so=so, useshrplib=true,
libperl=libperl.so.5.10.0
gnulibc_version='2.9'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
Built under linux
Compiled at Jun 26 2009 18:23:00
@INC:
/etc/perl
/usr/local/lib/perl/5.10.0
/usr/local/share/perl/5.10.0
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.
#
# end terminal output, resume comment
The answer's probably sitting right of nose, but I can't tell which one
it is.
Thanks for your comment,
--
John smith
------------------------------
Date: 15 Oct 2010 07:29:22 GMT
From: Huge <Huge@nowhere.much.invalid>
Subject: Re: why does this happen?
Message-Id: <8hqe6iF3ncU1@mid.individual.net>
On 2010-10-14, Sherm Pendley <sherm.pendley@gmail.com> wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
>> No. What Peter is saying is that it would not be unreasonable for an
>> editor's save-as function to behave like cp -p, rather than plain cp. In
>> the OP's case, he was expecting that editing an executable file and
>> saving it under another name would cause the new file to be executable:
>> this would be perfectly possible, it's just that Unix editors don't
>> happen to work like that.
>
> I would go a step further - it wouldn't be unreasonable for an editor
> to set the executable bit on any file that begins with a shebang, if of
> course the current umask allows it.
Yes it would. It goes against the Unix ethis of one tool doing one thing.
--
Today is Pungenday, the 69th day of Bureaucracy in the YOLD 3176
I ache in the places I used to play.
------------------------------
Date: Fri, 15 Oct 2010 03:51:22 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: why does this happen?
Message-Id: <m24ocnq4g5.fsf@sherm.shermpendley.com>
Huge <Huge@nowhere.much.invalid> writes:
> On 2010-10-14, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>>> No. What Peter is saying is that it would not be unreasonable for an
>>> editor's save-as function to behave like cp -p, rather than plain cp. In
>>> the OP's case, he was expecting that editing an executable file and
>>> saving it under another name would cause the new file to be executable:
>>> this would be perfectly possible, it's just that Unix editors don't
>>> happen to work like that.
>>
>> I would go a step further - it wouldn't be unreasonable for an editor
>> to set the executable bit on any file that begins with a shebang, if of
>> course the current umask allows it.
>
> Yes it would. It goes against the Unix ethis of one tool doing one thing.
There *is* such a thing as taking dogma too far, you know. At some
point, a little common sense needs to walk into the room.
When GCC creates an executable, you don't have to chmod +x it as a
separate step - the compiler does it for you. It's not a huge leap from
there to allowing an editor to do the same when saving edited script
files. If GCC is allowed to do it, why shouldn't Vim be allowed to?
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: 15 Oct 2010 09:21:54 GMT
From: Huge <Huge@nowhere.much.invalid>
Subject: Re: why does this happen?
Message-Id: <8hqkpiF7p8U1@mid.individual.net>
On 2010-10-15, Sherm Pendley <sherm.pendley@gmail.com> wrote:
> Huge <Huge@nowhere.much.invalid> writes:
>
>> On 2010-10-14, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>
>>>> No. What Peter is saying is that it would not be unreasonable for an
>>>> editor's save-as function to behave like cp -p, rather than plain cp. In
>>>> the OP's case, he was expecting that editing an executable file and
>>>> saving it under another name would cause the new file to be executable:
>>>> this would be perfectly possible, it's just that Unix editors don't
>>>> happen to work like that.
>>>
>>> I would go a step further - it wouldn't be unreasonable for an editor
>>> to set the executable bit on any file that begins with a shebang, if of
>>> course the current umask allows it.
>>
>> Yes it would. It goes against the Unix ethos of one tool doing one thing.
>
> There *is* such a thing as taking dogma too far, you know. At some
> point, a little common sense needs to walk into the room.
>
> When GCC creates an executable, you don't have to chmod +x it as a
> separate step - the compiler does it for you.
GCC's function is to create executables. It is not an editors function to
create executables.
--
Today is Pungenday, the 69th day of Bureaucracy in the YOLD 3176
I ache in the places I used to play.
------------------------------
Date: Fri, 15 Oct 2010 10:10:00 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: why does this happen?
Message-Id: <slrnibfvhv.div.whynot@orphan.zombinet>
with <m2iq14a0ld.fsf@sherm.shermpendley.com> Sherm Pendley wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
>> No. What Peter is saying is that it would not be unreasonable for an
>> editor's save-as function to behave like cp -p, rather than plain cp.
>> In the OP's case, he was expecting that editing an executable file
>> and saving it under another name would cause the new file to be
>> executable: this would be perfectly possible, it's just that Unix
>> editors don't happen to work like that.
>
> I would go a step further - it wouldn't be unreasonable for an editor
> to set the executable bit on any file that begins with a shebang, if
> of course the current umask allows it.
I beg to differ the whole trend here. An editor either can or can't
read a file (the latter case, file is unreadable). An editor either can
or can't create pre-rename(2) file (the latter case, file is
unwritable). Point. Anything else permission-related activity is,
let's say it, vulnerability. The vim's 'autocmd's (and AFAICO, emacs
has something same) are holes wide enough already.
If anyone wants more holes then the poor thing should switch to that
toy-OS.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Fri, 15 Oct 2010 22:24:49 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: why does this happen?
Message-Id: <slrnibhe4i.7uf.hjp-usenet2@hrunkner.hjp.at>
On 2010-10-14 21:51, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth J G Miller <miller@yoyo.ORG>:
>> On Thu, 14 Oct 2010 21:25:46 +0200, Peter J. Holzer wrote:
>> >
>> > Well, what does cp do in this case?
>>
>> With or without the -p flag? ;)
>>
>> > I don't see why "open file A in editor, save as B" should work
>> > differently than "cp A B".
>>
>> Do you really think that if the system allowed you to keep the
>> suid or guids permissions on files not belonging to you, that
>> would be good for security?
>
> No. What Peter is saying is that it would not be unreasonable for an
> editor's save-as function to behave like cp -p, rather than plain cp.
No, what I'm saying is that it would not be unreasonable for an editor's
save-as function to behave like plain cp, rather than always using mode
0666 (minus umask, but that's a function of the OS, not the editor).
Oh, and since some people here are touting the security card: The
current behaviour can be seen as a security risk, too: If you open a
file which is readable only by the group (or even only by the owner) and
you save it it, you might not expect that the new file is
world-readable and accidentally divulge confidential information.
hp
------------------------------
Date: Fri, 15 Oct 2010 22:29:41 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: why does this happen?
Message-Id: <slrnibhedm.7uf.hjp-usenet2@hrunkner.hjp.at>
On 2010-10-15 09:21, Huge <Huge@nowhere.much.invalid> wrote:
> On 2010-10-15, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>> Huge <Huge@nowhere.much.invalid> writes:
>>> On 2010-10-14, Sherm Pendley <sherm.pendley@gmail.com> wrote:
>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> No. What Peter is saying is that it would not be unreasonable for an
>>>>> editor's save-as function to behave like cp -p, rather than plain cp. In
>>>>> the OP's case, he was expecting that editing an executable file and
>>>>> saving it under another name would cause the new file to be executable:
>>>>> this would be perfectly possible, it's just that Unix editors don't
>>>>> happen to work like that.
>>>>
>>>> I would go a step further - it wouldn't be unreasonable for an editor
>>>> to set the executable bit on any file that begins with a shebang, if of
>>>> course the current umask allows it.
>>>
>>> Yes it would. It goes against the Unix ethos of one tool doing one thing.
Tell that to the Emacs people. Or the Vim people for that matter.
>> There *is* such a thing as taking dogma too far, you know. At some
>> point, a little common sense needs to walk into the room.
>>
>> When GCC creates an executable, you don't have to chmod +x it as a
>> separate step - the compiler does it for you.
>
> GCC's function is to create executables. It is not an editors function to
> create executables.
In many cases it is. Scripts are executables, and they are almost always
created with an editor.
hp
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3176
***************************************
