On Mon 14 Oct 2024 at 14:38:36 (-0400), Jim Anderson wrote:
I'm not sure why the Debian developers chose to change the behavior of
the 'more' command, but the Debian release 12 has the annoying habit,
upon reaching end of the file, of displaying extra empty lines to fill
a terminal window, then inserting the text:
(END)
at the end of file. This requires entering an unnecessary and annoying carriage return to restore the window to the terminal screen prompt.
I think you now need -e in a terminal:
-e, --exit-on-eof
Exit on End-Of-File, enabled by default if not executed on terminal.
Perhaps alias it?
I'm not sure why the Debian developers chose to change the behavior of
the 'more' command, but the Debian release 12 has the annoying habit,
upon reaching end of the file, of displaying extra empty lines to fill
a terminal window, then inserting the text:
(END)
at the end of file. This requires entering an unnecessary and annoying carriage return to restore the window to the terminal screen prompt.
One time usage is not bad, but if you use 'more' often, as I do, this behavior is a repeating waste of time. I hope the developers will
revert to the traditional behavior.
I'm not sure why the Debian developers chose to change the
behavior of the 'more' command, but the Debian release 12
has the annoying habit, upon reaching end of the file, of
displaying extra empty lines to fill a terminal window,
then inserting the text:
(END)
at the end of file. This requires entering an unnecessary
and annoying carriage return to restore the window to the
terminal screen prompt.
One time usage is not bad, but if you use 'more' often, as I do, this behavior is a repeating waste of time. I hope the developers will
revert to the traditional behavior.
For decades, I've had an alias like this:
alias l="ls -lF|more"
Convenient, no pager unless the directory listing is long. And now it's become this code:
more_version=$(more --version|awk '{print $4}'|cut -d. -f1-2)
if [[ $more_version -ge 2.38 ]]
then
alias l='ls -lF|more --exit-on-eof'
else
alias l='ls -lF|more'
fi
On Tue, Oct 15, 2024 at 3:40 AM Todd Zullinger <tmz@pobox.com> wrote:
For additional (and _possibly_ interesting) context, this
isn't a Debian-specific change. It's part of the upstream
util-linux-2.38 release¹. It was submitted to the
util-linux mailing list in 2021² and referenced the POSIX
specification as the rationale³.
¹ https://github.com/util-linux/util-linux/blob/master/Documentation/releases/v2.38-ReleaseNotes#L784
https://github.com/util-linux/util-linux/commit/df6b29d3b
(more: POSIX compliance patch preventing exit on EOF
without -e, 2021-09-29)
² https://lore.kernel.org/util-linux/20210624125918.GB2541@contractcoder.biz/
³ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html
Unexpected behavioral changes are always a pain. It is too bad it was
not hidden behind a variable like POSIXLY_CORRECT, like Bash does. See <https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html>.
Why did you make it so complicated? What's wrong with simply:
alias l='ls -lF|more -e'
or perhaps:
export MORE=-e
alias l='ls -lF|more'
Are you using some other shell, maybe? Like zsh?
On Wed, Oct 16, 2024 at 15:34:51 +0300, Anssi Saari wrote:
$ ls|more -e
more: unknown option -e
Try 'more --help' for more information.
I included the reason in my post by listing the Linux environments I use and where I expect this to work. Interestingly the man page for more in Debian 11 doesn't list -e but it seems to work anyway. But not on the others I mentioned.
I don't have access to a plethora of Linux distributions, so I wasn't
aware of how the -e option was treated by all of them.
Does the "export MORE=-e" variant work on the ones where -e is not
accepted as a command-line option? I would (perhaps naively) expect
that any unknown options in the MORE environment variable would be
silently ignored. But if that does throw an error, then... um... sorry,
I tried?
$ ls|more -e
more: unknown option -e
Try 'more --help' for more information.
I included the reason in my post by listing the Linux environments I use
and where I expect this to work. Interestingly the man page for more in Debian 11 doesn't list -e but it seems to work anyway. But not on the
others I mentioned.
Exporting MORE set to some unknown option (I did MORE=-q) leads to
more complaining and refusing service (so it seems to behave as if
one passed that option directly in the command line).
I still think that *conditionally* exporting MORE=-e (after performing whatever version-number-checking backflips are needed)
On Wed, Oct 16, 2024 at 15:48:07 +0200, tomas@tuxteam.de wrote:
Exporting MORE set to some unknown option (I did MORE=-q) leads to
more complaining and refusing service (so it seems to behave as if
one passed that option directly in the command line).
D'oh!
What a disaster. OK, now I have a better understanding of why people
are complaining so vocally about this change.
I still think that *conditionally* exporting MORE=-e (after performing whatever version-number-checking backflips are needed) is going to be
a better solution than changing individual aliases one by one.
On Wed, Oct 16, 2024 at 15:48:07 +0200, tomas@tuxteam.de wrote:
Exporting MORE set to some unknown option (I did MORE=-q) leads to
more complaining and refusing service (so it seems to behave as if
one passed that option directly in the command line).
D'oh!
What a disaster. OK, now I have a better understanding of why people
are complaining so vocally about this change.
I still think that *conditionally* exporting MORE=-e (after performing whatever version-number-checking backflips are needed) is going to be
a better solution than changing individual aliases one by one.
Greg Wooledge <greg@wooledge.org> wrote:
On Wed, Oct 16, 2024 at 15:48:07 +0200, tomas@tuxteam.de wrote:
Exporting MORE set to some unknown option (I did MORE=-q) leads to
more complaining and refusing service (so it seems to behave as if
one passed that option directly in the command line).
D'oh!
What a disaster. OK, now I have a better understanding of why people
are complaining so vocally about this change.
I still think that *conditionally* exporting MORE=-e (after performing whatever version-number-checking backflips are needed) is going to be
a better solution than changing individual aliases one by one.
Hasn't the whole linus/unix world moved to using less instead or more?
Chris Green wrote:
Hasn't the whole linus/unix world moved to using less instead or more?
If it continues to build and work, there's no reason to discard
it.
Some people have habits ingrained over 40 years, more or less.
On Wed, Oct 16, 2024 at 10:26:33AM -0400, Dan Ritter wrote:
Chris Green wrote:Yes, but on many systems (most?), when you type 'more' you actually get 'less'. You'd have to go out of your way to get the real more. :-)
Hasn't the whole linus/unix world moved to using less instead or more?
If it continues to build and work, there's no reason to discard
it.
Some people have habits ingrained over 40 years, more or less.
$ man more | head -n 11(on a Debian 11 system which started out as Debian 10, no particular
MORE(1) User Commands MORE(1)
NAME
more - file perusal filter for crt viewing
SYNOPSIS
more [options] file...
DESCRIPTION
more is a filter for paging through text one screenful at a time. This version is especially prim‐
itive. Users should realize that less(1) provides more(1) emulation plus extensive enhancements.
Some people have habits ingrained over 40 years, more or less.
This could be the next big emacs vs vi religious debate.
On Wed, Oct 16, 2024 at 10:26:33AM -0400, Dan Ritter wrote:
Chris Green wrote:
Hasn't the whole linus/unix world moved to using less instead or more?
If it continues to build and work, there's no reason to discard
it.
Some people have habits ingrained over 40 years, more or less.
Yes, but on many systems (most?), when you type 'more' you actually get 'less'. You'd have to go out of your way to get the real more. :-)
(I do use less, FWIW).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:16:45 |
| Calls: | 10,388 |
| Calls today: | 3 |
| Files: | 14,061 |
| Messages: | 6,416,822 |
| Posted today: | 1 |