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.
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.