Mailing List Archive

RFC - Issue a warning "-np better written as -p"
https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.

The PSC doesn't have any opinion on whether this is actually an idea
worth *implementing*. But we want to discuss it now, because it's a
simple suggestion that will explore some areas that need clarifying
before we start to consider more complex RFCs that also touch on them.


The text jidanni submitted to GitHub is:

perlrun says:
> A -p overrides a -n switch.

OK, but `-pnw` should warn:
"-np better written as -p"

just like it warns:
```
$ perl -awe 'print @F[1]'
Scalar value @F[1] better written as $F[1] at -e line 1.
```


I've turned this into the appended RFC, which weighs in at a massive 67
lines, and took me less than one cup of tea.

This is the sort of scale which I think many people could manage, and
sharing small tasks like this among many considerably reduces the
(perceived) workload of the few(er) folks who can implement these ideas.

Appended is the entire RFC, including the "discussion points" I wasn't
sure about.

Nicholas Clark

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

# Issue a warning "-np better written as -p"

## Preamble

Author:
Sponsor: Nicholas Clark <NWCLARK>
ID: 0003
Status: Draft

## Abstract

`perlrun` says *A **-p** overrides a **-n** switch.*

We warn for other overrides, such as variables declared twice. To be consistent we should warn for this one, if `-w` is on the command line.

## Motivation

We explicitly document that `-p` overrides `-n`. Calling the `perl` binary with both is not correct - the `-n` will be ignored. We could help users better by reporting their mistake to them, if they have opted into warnings.

## Rationale


For code, where what is written cannot make sense, we issue warnings. This is a similar case, just with command line flags

* Issuing a warning would make a programmer aware of the problem
* Issuing a warning would be consistent with our other use of warnings

## Specification

Invoking `perl` with all three of `-p`, `-w` and `-n` in any order or grouping should issue the warning

-np better written as -p

## Backwards Compatibility

This is **hard** to assess.

We can search CPAN for representative use of Perl **code**. With the demise of Google codesearch, there isn't a good way to search for command-line use cases of `perl`. Is it viable to search Debian's source archives? Or the FreeBSD ports tree?

Issuing a warning **might** break existing users' code, and they would be grumpy, because it was working, it would still work without a trapped warning, and we have no intention of changing the behaviour

It might "break" existing code, where users view "you're making new noise" as breakage, but (of course) everything still works.

It might not make much difference - do we have any feel for how many scripts invoking `perl` as a command-line *better sed*/*better awk* actually use `-w` **at all**?

## Security Implications

It's unclear whether there is any (direct) security implication.

## Examples

I believe that it's exhaustively covered in the *Specification*.

## Future Scope

We don't intend to make this warning "fatal".

## Rejected Ideas

## Open Issues

## Copyright

Copyright (C) 2021, Nicholas Clark

This document and code and documentation within it may be used, redistributed and/or modified under the same terms as Perl itself.
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Wed, 16 Jun 2021 08:51:19 +0000, Nicholas Clark wrote:

> ## Backwards Compatibility
>
> This is **hard** to assess.
>
> We can search CPAN for representative use of Perl **code**. With
> the demise of Google codesearch, there isn't a good way to search
> for command-line use cases of `perl`. Is it viable to search
> Debian's source archives? Or the FreeBSD ports tree?

For Debian the answer is yes:
https://codesearch.debian.net/

E.g. https://codesearch.debian.net/search?q=perl.*-np&literal=0
or https://codesearch.debian.net/search?q=perl.*-w.*-np&literal=0


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- BOFH excuse #365: parallel processors running perpendicular today
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Wed, Jun 16, 2021 at 10:59:29AM +0200, gregor herrmann wrote:
> On Wed, 16 Jun 2021 08:51:19 +0000, Nicholas Clark wrote:
>
> > ## Backwards Compatibility
> >
> > This is **hard** to assess.
> >
> > We can search CPAN for representative use of Perl **code**. With
> > the demise of Google codesearch, there isn't a good way to search
> > for command-line use cases of `perl`. Is it viable to search
> > Debian's source archives? Or the FreeBSD ports tree?
>
> For Debian the answer is yes:
> https://codesearch.debian.net/
>
> E.g. https://codesearch.debian.net/search?q=perl.*-np&literal=0
> or https://codesearch.debian.net/search?q=perl.*-w.*-np&literal=0

Merijn has also mentioned $PERL5OPT. I'd not thought of that.

(But on the original PR - please, can we keep discussion in one place. That
was part of the point of trying to have an RFC process - to avoid a spread
of discussion)

In trying out https://codesearch.debian.net/ I spotted that there was at
least one -np on a #! line.

So that's three places we need to consider, and the interaction between
them.


Right, so, I still don't have any good opinion on this, but within 30 minutes
we seem to have flushed out

1) "Command line" actually means all of argv, #! line and $PERL5OPT
2) https://codesearch.debian.net/ is useful for this

That was rather fast, and it's not even lunchtime yet.

Nicholas Clark
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Wed, Jun 16, 2021 at 4:51 AM Nicholas Clark <nick@ccl4.org> wrote:

> https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.
>

I don't think it's particularly useful to warn about this. Nothing is
broken or potentially broken by specifying unnecessary switches. I would
suggest it could become an optional warning if and when we add support for
that, but this would only come up for oneliners which are not likely to go
to the effort of enabling optional warnings of any sort.

-Dan
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
2021-6-16 17:51 Nicholas Clark <nick@ccl4.org> wrote:

> https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.
>
>
This idea is not so bad.

Has anyone actually specified both -n and -p options?
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Thu, Jun 17, 2021 at 08:41:06AM +0900, Yuki Kimoto wrote:
> 2021-6-16 17:51 Nicholas Clark <nick@ccl4.org> wrote:
>
> > https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.
> >
> >
> This idea is not so bad.
>
> Has anyone actually specified both -n and -p options?

If one follows the links to codesearch.debian.net in one of the other
messages in the thread, which my browser history thinks are:

https://codesearch.debian.net/search?q=perl.*-np&literal=0
https://codesearch.debian.net/search?q=perl.*-w.*-np&literal=0

There are 6 pages of results for the first, and one for the second.

Of course, these are only searching for specifically -np, and can have
false positives.

(For example I think that the results for fftw3 are a false positive - the
'-w' seems to be for perl, and the '-np' for something invoked via perl)


To get everything would require lots of permutations of searches (-pn,
-p -n, -n -p)

So yes, there are calls with -n and -p

What's not clear is

1) How many there are once the false positives go
2) How many are also invoked with -w

Nicholas Clark
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Wed, Jun 16, 2021 at 11:36:39AM -0400, Dan Book wrote:
> On Wed, Jun 16, 2021 at 4:51 AM Nicholas Clark <nick@ccl4.org> wrote:
>
> > https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.
> >
>
> I don't think it's particularly useful to warn about this. Nothing is
> broken or potentially broken by specifying unnecessary switches. I would
> suggest it could become an optional warning if and when we add support for
> that, but this would only come up for oneliners which are not likely to go
> to the effort of enabling optional warnings of any sort.

I'm going to guess the same for one-liners - they likely won't invoke
warnings. (The numbers from the Debian source searches suggest this)

But it can't be an *optional* warning, because if it is going to warn, it
needs to be enabled by '-w' on the command line, and I doubt that we're
going to change '-w' to be "optional too", or however we do it. I'd assume
that '-w' needs to keep meaning `use warnings`


However, skimming the source search results suggests that it's mostly
written as '-np'. And we document that '-p' overrides '-n', so this common
ordering is consistent with actual behaviour.

Maybe we should warn on '-pn' - ie order matters too - '-n' flag ignored.

Maybe not changing anything is best. I already said that I didn't know :-)

Nicholas Clark
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Thu, Jun 17, 2021 at 2:22 AM Nicholas Clark <nick@ccl4.org> wrote:

> On Wed, Jun 16, 2021 at 11:36:39AM -0400, Dan Book wrote:
> > On Wed, Jun 16, 2021 at 4:51 AM Nicholas Clark <nick@ccl4.org> wrote:
> >
> > > https://github.com/Perl/perl5/issues/18641 becomes our next test RFC.
> > >
> >
> > I don't think it's particularly useful to warn about this. Nothing is
> > broken or potentially broken by specifying unnecessary switches. I would
> > suggest it could become an optional warning if and when we add support
> for
> > that, but this would only come up for oneliners which are not likely to
> go
> > to the effort of enabling optional warnings of any sort.
>
> I'm going to guess the same for one-liners - they likely won't invoke
> warnings. (The numbers from the Debian source searches suggest this)
>
> But it can't be an *optional* warning, because if it is going to warn, it
> needs to be enabled by '-w' on the command line, and I doubt that we're
> going to change '-w' to be "optional too", or however we do it. I'd assume
> that '-w' needs to keep meaning `use warnings`
>
>
> However, skimming the source search results suggests that it's mostly
> written as '-np'. And we document that '-p' overrides '-n', so this common
> ordering is consistent with actual behaviour.
>
> Maybe we should warn on '-pn' - ie order matters too - '-n' flag ignored.
>

If this actually results in `-p` behavior being overridden, then I agree
this specific ordering should cause a warning.

-Dan
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Thu, Jun 17, 2021 at 2:50 AM Dan Book <grinnz@gmail.com> wrote:

> On Thu, Jun 17, 2021 at 2:22 AM Nicholas Clark <nick@ccl4.org> wrote:
>
>> Maybe we should warn on '-pn' - ie order matters too - '-n' flag ignored.
>>
>
> If this actually results in `-p` behavior being overridden, then I agree
> this specific ordering should cause a warning.
>

A brief test seems to show this case is fine - `-pn` and `-np` both result
in `-p` behavior.

-Dan
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
I am opposed to this change.

Below is my rationale.

On Wed, Jun 16, 2021, at 4:51 AM, Nicholas Clark wrote:
> perlrun says:
> > A -p overrides a -n switch.
>
> OK, but `-pnw` should warn:
> "-np better written as -p"
> […]
> just like it warns:
> ```
> $ perl -awe 'print @F[1]'
> Scalar value @F[1] better written as $F[1] at -e line 1.
> […]
> We explicitly document that `-p` overrides `-n`. Calling the `perl` binary with both is not correct - the `-n` will be ignored. We could help users better by reporting their mistake to them, if they have opted into warnings.

Using -p and -n is not causing one to be ignored. "-p" is "-n and also more". The gain to not writing both is saving a single (or perhaps 2-3) keystrokes. If the user has written both, their program will work just as well as one with only one. Removing one would require *more* work. Also, we'd need a warning message sufficiently clear that the user knew, immediately, to go remove the "n", but also that no change was really *required*. The benefit is very close to nil.

This is *not* the same as the @F[1] warning.

~$ perl -wE 'our @A = (1,2,3); say @A[0]'
Scalar value @A[0] better written as $A[0] at -e line 1.
1

Fine, no different, right? Actually, there's a massively important one that's simply not demonstrated by that code snippet:"

~$ perl -wE 'our @A; @A[0] = foo(); sub foo { warn wantarray ? "1\n" : "0\n" }'
1
~$ perl -wE 'our @A; $A[0] = foo(); sub foo { warn wantarray ? "1\n" : "0\n" }'
0

Using @A[0] creates a list context. Using $A[0] creates a scalar context. It's a setup for potentially deep confusion based on sigil variance, worth the warning.

--
rjbs
Re: RFC - Issue a warning "-np better written as -p" [ In reply to ]
On Fri, Jun 18, 2021 at 12:06:24PM -0400, Ricardo Signes wrote:
> I am opposed to this change.
>
> Below is my rationale.

The consensus seemed to be that this change wasn't worth the cost.
However, it did generate some useful discussion.

I've updated the RFC to rejected, and noted your rational in is as part of
the reason for rejection.

Nicholas Clark