Suggested Improvements to Staging's Implementation of the LS Command

[MasterO2]

Looking at the LS command that is now included with Dosbox-Staging, the following switches would also be useful to have included as well if that's possible:

-d, --directory  list directories themselves, not their contents
-h, --human-readable
-l, use a long listing format
-R, --recursive  list subdirectories recursively
-X, sort alphabetically by entry extension

https://www.man7.org/linux/man-pages/man1/ls.1.html

Also, for large directories that take more than one page to display, LS should be pipe-able to the more and less commands, since Staging's LS itself does not have the ability to scroll up or down.

[Grounded0]

Also, for large directories that take more than one page to display, LS should be pipe-able to the more and less commands, since Staging's LS itself does not have the ability to scroll up or down.

It already pipes just fine to more and less commands last time i checked though i have FreeDOS userland installed on top of DOSBox Staging.

[MasterO2]

Also, for large directories that take more than one page to display, LS should be pipe-able to the more and less commands, since Staging's LS itself does not have the ability to scroll up or down.

It already pipes just fine to more and less commands last time i checked though i have FreeDOS userland installed on top of DOSBox Staging.

I tried piping LS into less using the less command found at https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/less.html and LS did not scroll at all.

[Grounded0]

More:

Less:

As i said i have non-standard installation so if someone has energy to check against bog-standard DOSBox Staging install to confirm it actually doesn't work then thank you.

[brandonrobertz]

As i said i have non-standard installation so if someone has energy to check against bog-standard DOSBox Staging install to confirm it actually doesn't work then thank you.

I've confirmed what MasterO2 is saying on a default dosbox-staging environment. Running FreeDOS is probably getting you a pipe that works more robustly.

[MasterO2]

@Wengier In addition to adding the ability to pipe commands to Staging, would you also be willing to add the above improvements to the LS command?

[Wengier]

@MasterO2 As a command originally from *nix systems, LS command has a lot of *nix-like options. I hope to clean up and convert some particularly useful ones to DOS style (e.g. /d instead of -d or --directory) to work in DOSBox (which is a DOS emulator). But the details can be discussed.

[Wengier]

Piping is supported via PR #1517.

[kcgen]

Thanks for these additions @Wengier .

Regarding LS, it's only purpose is to keep muscle-memory intact for users primarily coming from Linux / macOS / BSD / MSYS2. They can continue to rapidly type ls (and common flags) without having to think twice.

I hope to clean up and convert some particularly useful ones to DOS style (e.g. /d instead of -d or --directory)

We don't want to take away its GNU-style dash flags: doing so would confuse that muscle-memory: "Wait, does this one need -d or /d?"). But there's no harm in mapping DOS-style slashes to the existing GNU single-dash flags! (apologies if that what you intended).

[Wengier]

@kcgen I certainly understand the purpose you mentioned, since I have similar experiences. For example, Linux provides both dir and ls commands, and I personally usually use the former. But in macOS, only ls command is provided by default, so I had to always ensure a command like alias dir=ls is in the shell script (e.g. .bashrc) so that dir will also work as expected in macOS. I surely understand that some other users may be more used to ls command.

There is of course no need to completely take away the GNU style flags - we can always keep both. For example, for several DOS shell commands the options /? and -? are treated as identical. It is good to support both so that different users can use the options according to their preferences, and the implementation to allow both styles can be done easily.

Also, note that LS command may not very well with commands like LESS when there are color codes, due to the way that redirection works. This happens regardless of the command shell, such as the internal shell, or the command shells from MS-DOS or FreeDOS. This will become very noticeable when many directory entries are colored, and fixing the LS command itself appears to be the only solution for now.

[kcgen]

All sounds good!
Great point regarding coloured output and the impact on downstream stdin sinks.

On Linux, most CLI tools use a couple simple boolean library calls to determine if their output is going to a pipe versus and interactive terminal, and then adjust colorization to suit. (https://unix.stackexchange.com/a/515781)

I suppose on the DOSBox side, when everything is visible under our own shell we can provide such information internally. But I wonder if the real command.com provided a handler for programs to discover this information?

[Wengier]

@kcgen When we use the internal command shell and internal implementation of LS command, it is relatively easy to fix them (I did have sample fixes in the X code). But when the code involves outside command shells or command implementations, it becomes much harder. I have tried the command.com from real DOS (the screenshot below using FreeCOM) and downloaded LESS command, and the output is something like the following:

[Grounded0]

LESS command doesn't belong in a DOS anyway. Anybody that pipes in a DOS probably knows this. Wouldn't spend time on a command that doesn't belong to the official FreeDOS Base Installation. LESS is an external third party utility included in a more comprehensive FreeDOS Full Installation. Solution might be to redirect LESS into MORE.

[Wengier]

Strictly speaking neither LS nor LESS is a standard DOS command, but they have been ported to DOS as part of DJGPP for a long time. FreeDOS later bundles them anyway, but they can be used in any DOS, not just FreeDOS. While there may not be necessary to add more non-standard DOS commands (this can be discussed on a case-by-case basis), whether a command belongs to the FreeDOS base installation has no direct connections with whether it should be included in our project. The LS command for example is not a FreeDOS base command but has included for some time, and much work has been done on it.

[Grounded0]

Well it can be included as LESS redirecting into MORE or writing our internal LESS that works better. Personally i'm not a fan of duplicating Unix commands or idioms into DOS because Unix is Unix and DOS is DOS and users have to realise this. Even pipes are not native to DOS but they're being offered.

[Grounded0]

Using a LESS command that is open source from some other project could be helpful. If DJGPP LESS works better maybe we should look into that if we cannot just redirect LESS into MORE which works well enough for most. It's a rabbit hole.

[kcgen]

Let's stay away from rabbit holes! 🐇

[MasterO2]

Now that Staging has the ability to pipe, (cca0084), what does Staging want to do about improving Staging's implementation of the LS command?

[Wengier]

I implemented MORE command and fix for LS command in PR #1556.

[Burrito78]

Road to nowhere, here i come. Closed for now during spring cleaning.