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

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

Open
p5pRT opened this issue Sep 20, 2018 · 14 comments
Open

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

p5pRT opened this issue Sep 20, 2018 · 14 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 20, 2018

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

Searchable as RT133533$

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 2018

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
Copy link
Author

p5pRT commented Sep 20, 2018

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
Copy link
Author

p5pRT commented Sep 20, 2018

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

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 2018

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
Copy link
Author

p5pRT commented Sep 22, 2018

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
Copy link
Author

p5pRT commented Sep 22, 2018

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
Copy link
Author

p5pRT commented Sep 22, 2018

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
Copy link
Author

p5pRT commented Sep 22, 2018

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
Copy link
Author

p5pRT commented Sep 23, 2018

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
Copy link
Author

p5pRT commented Sep 23, 2018

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
Copy link
Author

p5pRT commented Sep 25, 2018

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
Copy link
Author

p5pRT commented Sep 25, 2018

From @Tux

On Tue, 25 Sep 2018 11​:25​:38 +0100, Dave Mitchell <davem@​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
Copy link
Author

p5pRT commented Sep 25, 2018

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
Copy link
Author

p5pRT commented Sep 25, 2018

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

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