Feature request: arbitrary arguments order

[elig0n]

Currently command line arguments to less must be specified before the filename/s.
Maybe it's possible to make it make it accepted anywhere ? I.e.

less file1.txt +G

[gwsw]

Most Unix-like commands have options before filename arguments. What would be the advantage in making less behave in this unusual way?

[avih]

What would be the advantage in making less behave in this unusual way?

I'd guess that it's easier to edit the command for the next time (after recalling it from history) by moving the cursor smaller distance to change the options at the end.

Most Unix-like commands have options before filename arguments.

That depends. POSIX getopt (and plan9 ARGBEGIN macro) does behave that way, but gnu getopt (the standard getopt in glibc) by default allows options also after the operands, unless POSIXLY_CORRECT is set in env.

So on a gnu/linux system, by default options are allowed also after the operands as long as the app uses the libc getopt.

FWIW, permuting the arguments like gnu getopt does by default is not worth it in less IMO. I did implement it in the past (gnu-like getopt), but less options are already complex enough, and I don't think it's worth the added complexity.

[gwsw]

I'd guess that it's easier to edit the command for the next time (after recalling it from history) by moving the cursor smaller distance to change the options at the end.

I don't know about that. Is it more likely that the user would want to change the options or change the filename? And you can change most options within less using the - command without even exiting. I agree that adding complexity to the option processing would require a compelling rationale.

[avih]

Is it more likely that the user would want to change the options or change the filename?

Does it matter which is more popular? it depends on the use case, and these are not mutually exclusive. If one is investigating in order to figure out the form to put in some script, then the options are the variable, while in "normal" usage the file is the variable.

Allowing options at the end doesn't take away anything from one use case, and makes it more convenient with the other use case.

I've certainly experimented with options repeatedly using a single test file, where it would have been more convenient if options at the end were allowed.

That being said, I still think it's relatively minor, and that it's not worth the effort and added complexity.

If you are interested in supporting it, then the approach by gnu getopt (and those who imitate it) is to permute the options (argv) during the parsing by moving operands to the end as they're encountered (i.e. any argument which would otherwise be considered non-option and therefore end-of-options is moved to the end of the list, and options parsing continues with the following argument, except for -- which still terminates the options parsing, or we've reached-again the first operand which was moved to the end, or there are no more arguments), so that once parsing of all options is complete, all the operands end up are at the end of the list, as if all the options were at the begining and all the operands at the end (with optind holding a normal value in this scenario), and then the application processes the operands sequentially normally - like with standard getopt.

It should probably support the env to disable it too.

It's not rocket science, but it does add some complexity, for arguably not huge fuctional value, but with some familiarity value compared to other apps on some systems.

[gwsw]

Well, this change turned out to be much simpler than I expected. I believe that this is implemented in 2278c2e.

I just started a beta cycle yesterday and didn't intend to add any new features, but I may include this since it was quite simple.

[avih]

I still suggest to support env POSIXLY_CORRECT too to disable this behavior when this env is set (even if empty - just like gnu getopt).

[gwsw]

POSIXLY_CORRECT is already supported.

[avih]

Right. I only checked ff7daa7 , and didn't realize 2278c2e also exists.

[gwsw]

In 1d21e57 I have made POSIXLY_CORRECT be treated as TRUE if it set to an empty string. That seems weird to me, but it is compatible with gnu.