adding other bash file ops like '-nt, -ot, etc..'

[p5pRT]

Migrated from rt.perl.org#133533 (status was 'open')

Searchable as RT133533$

[p5pRT]

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

It seems that the various -X operators are intended to mirror those existing in the shell.

I noticed that an operator like -nt was only implemented by   (stat('file1'))[9] > (stat('file2'))[9]

which seems a bit obtuse.

How difficult would it be to add the remaining file-compare operators as listed in posix. It might make it a bit easier for shell programmers to feel comfortable in in perl and not use expressions like the above.

I'm not suggesting the various string operators be implemented -- those are well handled by perl ops\, but the file ops as would be used to test conditions with external files would seem to benefit by such a simplification.

Thanks.  

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl 5.16.3: Configured by law at Wed Jan 22 12:58:58 PST 2014. Summary of my perl5 (revision 5 version 16 subversion 3) configuration: Platform: osname=linux, osvers=3.12.0-isht-van, archname=x86_64-linux-thread-multi-ld uname='linux ishtar 3.12.0-isht-van #1 smp preempt wed nov 13 16:50:51 pst 2013 x86_64 x86_64 x86_64 gnulinux ' config_args='' hint=previous, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g -O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='4.8.1 20130909 [gcc-4_8-branch revision 202388]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=16, prototype=define Linker and Libraries: ld='gcc', ldflags ='-g -fstack-protector -fPIC' libpth=/usr/lib64 /lib64 libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.18.so, so=so, useshrplib=true, libperl=libperl-5.16.3.so gnulibc_version='2.18' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld/CORE' cccdlflags='-fPIC', lddlflags='-shared -g -O2 -fstack-protector -fPIC' Locally applied patches: @INC for perl 5.16.3: /home/law/bin/lib /home/perl/perl-5.16.3/lib/site/x86_64-linux-thread-multi-ld /home/perl/perl-5.16.3/lib/site /home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld /home/perl/perl-5.16.3/lib . Environment for perl 5.16.3: HOME=/home/law LANG (unset) LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/sbin:/home/law/bin/lib:/home/law/bin:/usr/bin:/bin:/opt/kde3/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL5OPT=-Mutf8 -CSA -I/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @leonerd

On Thu\, 20 Sep 2018 06​:10​:09 -0700 "Linda Walsh \(via RT\)" \perlbug\-followup@​perl\.org wrote​:

It seems that the various -X operators are intended to mirror those existing in the shell.

I noticed that an operator like -nt was only implemented by (stat('file1'))[9] > (stat('file2'))[9]

which seems a bit obtuse.

How difficult would it be to add the remaining file-compare operators as listed in posix. It might make it a bit easier for shell programmers to feel comfortable in in perl and not use expressions like the above.

I'd say that sounds terrible. Those -X operators are already somewhat obtuse to anyone who doesn't recognise them from a shell - adding more would be difficult in a compatibility perspective as well as make the situation worse for understanding.

I'd say a far better plan would be to just add some more methods to the File​::stat package. Already you ought to be using it -anyway-\, so your example above should read

  use File​::stat;

  stat("file1")->mtime > stat("file2")->mtime

at which point\, it has no back-compat problems and reads nicer to the unfamiliar\, to add a method like

  stat("file1")->newer_than(stat("file2"))

-- Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk | https://metacpan.org/author/PEVANS http​://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

[p5pRT]

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

[p5pRT]

From @iabyn

On Thu\, Sep 20\, 2018 at 02​:32​:02PM +0100\, Paul "LeoNerd" Evans wrote​:

On Thu\, 20 Sep 2018 06​:10​:09 -0700 "Linda Walsh \(via RT\)" \perlbug\-followup@​perl\.org wrote​:

It seems that the various -X operators are intended to mirror those existing in the shell.

I noticed that an operator like -nt was only implemented by (stat('file1'))[9] > (stat('file2'))[9]

which seems a bit obtuse.

How difficult would it be to add the remaining file-compare operators as listed in posix. It might make it a bit easier for shell programmers to feel comfortable in in perl and not use expressions like the above.

I'd say that sounds terrible.

+1.

Also\, it's already valid syntax​:

  $ perl -MO=Deparse -e'$f1 -nt $f2'   $f1 - $f2->nt;

  $ perl -MO=Deparse -e'sub nt{} $f1 -nt $f2'   ...   $f1 - nt($f2);

-- O Unicef Clearasil! Gibberish and Drivel!   -- "Bored of the Rings"

[p5pRT]

From perl-diddler@tlinx.org

On 9/20/2018 6​:39 AM\, Paul LeoNerd Evans via RT wrote​:

I'd say that sounds terrible.

---

  Civility is simple​: stick to the facts while avoiding demeaning remarks\,   belittling other individuals\, sarcasm\, or a presumption of bad faith. It   is not enough to be factual. You must also be civil. Responding in kind to   incivility is not acceptable. If you relay otherwise-unposted comments to   the list from a third party\, you take responsibility for the content of   those comments\, and you must therefore ensure that they are civil.

  While civility is required\, kindness is encouraged; if you have any doubt   about whether you are being civil\, simply ask yourself\, "Am I being kind?"   and aspire to that.

I submit that your statement was neither civil nor kind.

Those -X operators are already somewhat obtuse to anyone who doesn't recognise them from a shell - adding more would be difficult in a compatibility perspective as well as make the situation worse for understanding.

And that is a matter of opinion. Most people will learn shell programming on a unix or linux machine before they learn perl.

Perl was designed to be a merge of shell and several of its utilities. That it might become more so doesn't seem confusing at all.

[p5pRT]

From perl-diddler@tlinx.org

On 9/20/2018 7​:20 AM\, Dave Mitchell via RT wrote​:

On Thu\, Sep 20\, 2018 at 02​:32​:02PM +0100\, Paul "LeoNerd" Evans wrote​:

I'd say that sounds terrible.

+1.

---

  This is neither civil nor kind either. Your responses would no doubt warrant me a warning\, but will likely be unremarked on with any seriousness by anyone you would care about. I just compare people to dinosaurs\, and get banned for 6+ years?

Also\, it's already valid syntax​:

$ perl \-MO=Deparse \-e'$f1 \-nt $f2'
$f1 \- $f2\->nt;

---

  No. That's inconsistent with how the current ops are parsed​:

perl -MO=Deparse -e '$f1 -u $f2'
syntax error at -e line 1\, near "$f1 -u " -e had compilation errors.

According to you\, that should have been parsed $f1 - $f2->u

$ perl \-MO=Deparse \-e'sub nt\{\} $f1 \-nt $f2'
\.\.\.
$f1 \- nt\($f2\);

perl -MO=Deparse -e 'sub u{} $f1 -u $f2' syntax error at -e line 1\, near "$f1 -u " -e had compilation errors. sub u {  
}

According to you\, it should have been 'fine' and interpreted as​: $f1 - u($f2)

The reality is that perl only parses in the ways you mention when '-nt' is not an existing operator.

2nd\, the prefix form of calling a member has been semi-deprecated.

Though if you can show either of the above constructs in the existing body of cpan code\, I would agree that adding them would be unacceptable.

[p5pRT]

From andreas@guldstrand.info

On Sat\, 22 Sep 2018 at 12​:34\, L. Walsh \perl\-diddler@​tlinx\.org wrote​:

On 9/20/2018 7​:20 AM\, Dave Mitchell via RT wrote​:

Also\, it's already valid syntax​:

$ perl \-MO=Deparse \-e'$f1 \-nt $f2'
$f1 \- $f2\->nt;

---- No. That's inconsistent with how the current ops are parsed​:

Exactly! If you make -nt an operator it would cause that code to change how it's being parsed.

[...] The reality is that perl only parses in the ways you mention when '-nt' is not an existing operator.

This is precisely why it's backwards incompatible. -nt is not currently an operator\, so making it into one will break old code that used code like he showed.

2nd\, the prefix form of calling a member has been semi-deprecated.

I'm not sure what you mean by member here\, but I'm going to assume you mean a method\, and specifically what's referred to as an indirect method call... and I believe you're wrong when you say it's been semi-deprecated.

It has been -discouraged- by members of the perl community because it is hard to reason about what it means since the meaning changes if you have a subroutine with that name already declared. This does not mean it's been documented by perl as being discouraged\, and it does not mean it's semi-deprecated.

Secondly\, when it comes to civility\, you qouted something\, I'm not sure what​:

Civility is simple​: stick to the facts while avoiding demeaning remarks\, belittling other individuals\, sarcasm\, or a presumption of bad faith.

I don't see how Paul thinking that your idea was a terrible one is a demeaning remark\, I don't see how it is belittling anyone\, it did not sound like sarcasm or a presumption of bad faith. Your civility attack however does specifically sound like a presumption of bad faith.

[p5pRT]

From @iabyn

On Sat\, Sep 22\, 2018 at 03​:33​:32AM -0700\, L. Walsh wrote​:

On 9/20/2018 7​:20 AM\, Dave Mitchell via RT wrote​:

On Thu\, Sep 20\, 2018 at 02​:32​:02PM +0100\, Paul "LeoNerd" Evans wrote​:

I'd say that sounds terrible.

+1. --- This is neither civil nor kind either.

This wasn't a personal attack\, it was agreement with an honest criticism of a suggestion.

Your responses would no doubt warrant me a warning\,

No it wouldn't. If you said for example\, "that is a stupid idea and you are a stupid person" then you would have been warned.

I just compare people to dinosaurs\, and get banned for 6+ years?

That's a personal attack. Also\, you got banned for a long accumulation of personal attacks\, not for a single incident.

Also\, it's already valid syntax​:

$ perl \-MO=Deparse \-e'$f1 \-nt $f2'
$f1 \- $f2\->nt;

---- No. That's inconsistent with how the current ops are parsed​: perl -MO=Deparse -e '$f1 -u $f2' syntax error at -e line 1\, near "$f1 -u " -e had compilation errors.

According to you\, that should have been parsed $f1 - $f2->u

You're confusing unary and binary operators. All the current perl filetest operators are unary ops. You're proposing to introduce *binary* filtest ops\, which introduces a new set of parsing issues.

My example was pointing out that your proposed syntax is ambiguous - it already has a valid interpretation by the parser\, and you want to introduce a second meaning\, which the parser would need to disambiguate.

As another example\,

  $f1-nt($f2)

should that be parsed as a function call​:   $f1 - nt($f2) or as a filetest​:   $f1 -nt $f2

This opens a can of worms for very little gain.

Your example of a -nt operator can already be written easily as   -M $f1 \< -M $f2

-- "Do not dabble in paradox\, Edward\, it puts you in danger of fortuitous wit."   -- Lady Croom\, "Arcadia"

[p5pRT]

From perl-diddler@tlinx.org

On 9/22/2018 4​:38 AM\, Dave Mitchell via RT wrote​:

On Sat\, Sep 22\, 2018 at 03​:33​:32AM -0700\, L. Walsh wrote​:

On 9/20/2018 7​:20 AM\, Dave Mitchell via RT wrote​:

On Thu\, Sep 20\, 2018 at 02​:32​:02PM +0100\, Paul "LeoNerd" Evans wrote​:

I'd say that sounds terrible.

+1.

--- This is neither civil nor kind either.

This wasn't a personal attack\, it was agreement with an honest criticism of a suggestion.

---

  I didn't say it was a personal attack. I said it wasn't civil nor was it kind.

I just compare people to dinosaurs\, and get banned for 6+ years?

That's a personal attack. Also\, you got banned for a long accumulation of personal attacks\, not for a single incident.

---

  Funny\, when I asked for examples of violations none could be given. Comparing the behavior of those who could not evolve to a species that supposedly died out for not being able to do so is an impersonal attack at worst\, however\, it was a honest criticism that I felt would cause a large decline in perl users. Perl has lost close to 75-70% of users since then and ranks dead last in languages used in some recent programming language polls. It certainly was not meant personally\, as it was a generic description of behavior.

Also\, it's already valid syntax​:

$ perl \-MO=Deparse \-e'$f1 \-nt $f2'
$f1 \- $f2\->nt;

---- No. That's inconsistent with how the current ops are parsed​:

perl -MO=Deparse -e '$f1 -u $f2'

syntax error at -e line 1\, near "$f1 -u " -e had compilation errors.

According to you\, that should have been parsed $f1 - $f2->u

You're confusing unary and binary operators. All the current perl filetest operators are unary ops. You're proposing to introduce *binary* filtest ops\, which introduces a new set of parsing issues.

---

  I'm not confusing the ops -- I showed an example that is equally ambiguous with the current operators. The parser wouldn't have to work any harder than it already does.

My example was pointing out that your proposed syntax is ambiguous - it already has a valid interpretation by the parser\, and you want to introduce a second meaning\, which the parser would need to disambiguate.

As another example\,

$f1\-nt\($f2\)

$f1 -r($f2) -- is another example of a unary operator that has a similar problem.

If "-r" is a valid operator\, it is parsed one way\, if "-Q is not a valid operator it is parsed a 2nd way. The ambiguity you mention is already there.

Your example of a -nt operator can already be written easily as -M $f1 \< -M $f2

---

  There are tons of ways to write it\, but none that would work both in shell and perl

[p5pRT]

From @khwilliamson

On 09/23/2018 01​:22 AM\, L. Walsh wrote​:

On 9/22/2018 4​:38 AM\, Dave Mitchell via RT wrote​:

On Sat\, Sep 22\, 2018 at 03​:33​:32AM -0700\, L. Walsh wrote​:

On 9/20/2018 7​:20 AM\, Dave Mitchell via RT wrote​:

On Thu\, Sep 20\, 2018 at 02​:32​:02PM +0100\, Paul "LeoNerd" Evans wrote​:

I'd say that sounds terrible. +1. ---    This is neither civil nor kind either.

This wasn't a personal attack\, it was agreement with an honest criticism of a suggestion. ----    I didn't say it was a personal attack.  I said it wasn't civil nor was it kind.

I don't believe the first replies to Linda were appropriate even if they are legal under our policies.

Saying that something is a terrible idea without any supporting reasoning\, is demeaning. It sounds like the writer saying that believes he is some god\, making pronouncements from on high that us mere mortals must follow without questioning.

If someone doesn't have the time or patience to respond in depth\, then I think it's better to remain silent until someone does so respond\, and then one can just say +1 to that in depth response.

Karl Williamson

[p5pRT]

From @iabyn

On Sun\, Sep 23\, 2018 at 12​:22​:07AM -0700\, L. Walsh wrote​:

This is neither civil nor kind either.

This wasn't a personal attack\, it was agreement with an honest criticism of a suggestion. ---- I didn't say it was a personal attack. I said it wasn't civil nor was it kind.

Ok\, I apologise.

I'm not confusing the ops -- I showed an example that is equally ambiguous with the current operators. The parser wouldn't have to work any harder than it already does.

The existing filetest operators were added in perl 2\, back when you had to call subroutines using the 'do funcname(args)' syntax\, so there was no ambiguity. When direct function calls were later added\, i.e. 'funcname(args)'\, the new ambiguity could be resolved by the lexer in favour of the filetest operators without any risk of breaking existing code.

The problem we would have in adding new filetest operators is that any resolution of ambiguity in favour of the new operators could break existing code.

Also\, the handling of the '-' token in the lexer is currently rather complex. It handles the '-' token in all the following different ways depending on context​:

  - as a unary negation operator   - as a binary subtraction operator   -r $file as a filetest operator   -foo as the auto-quoted bareword "-foo"   -r => 1 as the auto-quoted bareword "-r"

Further\, the lexer is sensitive to operator/term context\, for example when expecting a term\, the '/' token is interpreted as the start of a pattern\, while when expecting an op\, its treated as a division​:

  $match_result = / .... # lexer returns match token   $foo / .... # lexer returns divide token

By adding binary filetest ops\, we have to make the lexer more sensitive to term/op context in resolving what a '-' token means\, adding more complexity to already complex code.

Your example of a -nt operator can already be written easily as -M $f1 \< -M $f2 --- There are tons of ways to write it\, but none that would work both in shell and perl

Having syntax that works in both shell and perl is not a high priority for me. While 20-30 years ago most people may have arrived at perl via a shell/awk/sed background\, I think that's a minority now.

Note also that perl has a whole bunch of filetest ops that bash doesn't have\, like -M\, plus ops that mean different things in perl and bash\, like -z. So we can never make them fully compatible anyway.

My position on this proposal is that it adds very little usefulness to perl\, and what it does add can be done easily enough with existing perl syntax anyway. Adding such ops involves the risk of breaking existing code or introducing subtle bugs in the lexer's already complex handing of the '-' token.

So I am not in favour of this proposal.

-- It's not that I'm afraid to die\, I just don't want to be there when it happens.   -- Woody Allen

[p5pRT]

From @tux

On Tue\, 25 Sep 2018 11​:25​:38 +0100\, Dave Mitchell \davem@&#8203;iabyn\.com wrote​:

On Sun\, Sep 23\, 2018 at 12​:22​:07AM -0700\, L. Walsh wrote​: [...]

This wasn't a personal attack\, it was agreement with an honest criticism of a suggestion.
---- I didn't say it was a personal attack. I said it wasn't civil nor was it kind.

Ok\, I apologise.

I'm not confusing the ops -- I showed an example that is equally ambiguous with the current operators. The parser wouldn't have to work any harder than it already does.

The existing filetest operators were added in perl 2\, back when you had to call subroutines using the 'do funcname(args)' syntax\, so there was no ambiguity. When direct function calls were later added\, i.e. 'funcname(args)'\, the new ambiguity could be resolved by the lexer in favour of the filetest operators without any risk of breaking existing code.

The problem we would have in adding new filetest operators is that any resolution of ambiguity in favour of the new operators could break existing code.

Also\, the handling of the '-' token in the lexer is currently rather complex. It handles the '-' token in all the following different ways depending on context​:

\-          as a unary negation operator
\-          as a binary subtraction operator
\-r $file   as a filetest operator
\-foo       as the auto\-quoted bareword "\-foo"
\-r => 1    as the auto\-quoted bareword "\-r"

Additionally

  $-   @​-   %-   $a->method   $a->[0]   $a->{x}   m-foo-   s-foo-bar-   $a--   --$a

$ perl -MTime​::Piece -wE'$_=Time​::Piece->new;say$_--->week;' 39 $ perl -wE'$-=12;say$---;say$-' 12 11

Further\, the lexer is sensitive to operator/term context\, for example when expecting a term\, the '/' token is interpreted as the start of a pattern\, while when expecting an op\, its treated as a division​:

$match\_result = / \.\.\.\.    \# lexer returns match token
$foo /            \.\.\.\.    \# lexer returns divide token

By adding binary filetest ops\, we have to make the lexer more sensitive to term/op context in resolving what a '-' token means\, adding more complexity to already complex code.

Your example of a -nt operator can already be written easily as -M $f1 \< -M $f2
--- There are tons of ways to write it\, but none that would work both in shell and perl

Having syntax that works in both shell and perl is not a high priority for me. While 20-30 years ago most people may have arrived at perl via a shell/awk/sed background\, I think that's a minority now.

Note also that perl has a whole bunch of filetest ops that bash doesn't have\, like -M\, plus ops that mean different things in perl and bash\, like -z. So we can never make them fully compatible anyway.

My position on this proposal is that it adds very little usefulness to perl\, and what it does add can be done easily enough with existing perl syntax anyway. Adding such ops involves the risk of breaking existing code or introducing subtle bugs in the lexer's already complex handing of the '-' token.

So I am not in favour of this proposal.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From perl-diddler@tlinx.org

On 9/25/2018 3​:26 AM\, Dave Mitchell via RT wrote​:

lready does.

The existing filetest operators were added in perl 2\, back when you had to call subroutines using the 'do funcname(args)' syntax\, so there was no ambiguity. When direct function calls were later added\, i.e. 'funcname(args)'\, the new ambiguity could be resolved by the lexer in favour of the filetest operators without any risk of breaking existing code.

1) To be clear\, at this point\, there are only 3 such operators​: 'nt' 'ot' and 'ef' ('equal file'​: referring to same device and inode number.

2) At the least\, one would have to enable the new operators via 'use perl5.xxx' or enable their use lexically via "use/no" 'Extended_Filetests'.

3) If it was decided to use -nt/-ot/-ef\, those operators would be like the pattern binding operator '=~'. If they occur together and are not part of a longer word\, e.g. "-ntos"\, and resolvable SCALARs are on either side\, then precedence would be given to interpreting the the usage as an operator.

Your example of a -nt operator can already be written easily as -M $f1 \< -M $f2

--- There are tons of ways to write it\, but none that would work both in shell and perl

Having syntax that works in both shell and perl is not a high priority for me. While 20-30 years ago most people may have arrived at perl via a shell/awk/sed background\, I think that's a minority now.

Note also that perl has a whole bunch of filetest ops that bash doesn't have\, like -M\, plus ops that mean different things in perl and bash\, like -z. So we can never make them fully compatible anyway.

---

  Looking at the man page in bash\, I don't -M in the file operators I do see -M used as a standalone value meaning 'script start time'. If it were desired\, -M ARG could give mod time while "$x = -M;" could indicate the perl-script's start time\, BUT\, I wasn't thinking of that usage\, nor do I see it being quite as useful.

  Certain -z could be reconciled with -z returning 0 if the arg\, as a file was 0 bytes\, or if the arg was an empty (but defined) string\, e.g. "".
While a cute interpretation\, I'm not sure how clear it would be in code-usage.

  Unfortunately this is a case of selling a feature to perl-experts\, where it's usefulness would be more likely to appeal to non-perl experts. Perl experts are likely to come up with a very different set of features they want to see\, than ones that would be interesting or good for non-perl experts.

  Given the direction of perl's popularity among the non-perl-expert group\, some features changed in the past 5-10 years might benefit from a revisiting from the viewpoint of non-perl experts\, regardless of the probable non-appeal of that view to this group.

[p5pRT]

From m@rtij.nl

Op 25-09-18 om 12​:25 schreef Dave Mitchell​:

Having syntax that works in both shell and perl is not a high priority for me. While 20-30 years ago most people may have arrived at perl via a shell/awk/sed background\, I think that's a minority now.

As someone who works daily with sysadmins\, engineers and developers\, I disagree with this statement. It's a common frame of reference\, even today still. I do agree with your other objections though.

Regards\, Martijn "M4" Lievaart