Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ls output formatting #43

Closed
rennergade opened this issue Dec 23, 2019 · 2 comments
Closed

ls output formatting #43

rennergade opened this issue Dec 23, 2019 · 2 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers

Comments

@rennergade
Copy link
Contributor

Currently running ls through Lind gives us something like

�.
�..
�bin
�dev
�lib
dc.nexe
forkexecarg.nexe
forkexecls.nexe
forkexecv.nexe
hello.nexe
Persisting metadata: ...
Done persisting metadata.
Terminated

The formatting runs into even more problems when additional flags are introduced. I think some of the flags may be due to unimplemented syscalls. OTOH the general formatting (rogue nonsense characters and extra newlines) is almost certainly due to the weird stdout buffering discussed here.

@rennergade rennergade added enhancement New feature or request bug Something isn't working labels Dec 23, 2019
@rennergade
Copy link
Contributor Author

The mega-merge uncovered an old commit that got rid of the nonsense-chars which is most of the battle here. There still seems to be newlines after each item in ls which doesn't happen natively.

I originally thought this was because of NaCl's stdout buffering problem, but it seems that write is actually receiving this whole block of text separated by newlines at one time, so that's not it. At this point it seems that getdents is actually inserting these extra newlines. Most likely on the NaCl-side in the NaClStreamDirents function.

This would be a good first issue for someone wanting to work on the NaCl side of lind.

@rennergade rennergade added the good first issue Good for newcomers label Mar 26, 2020
@jesings
Copy link
Member

jesings commented Jul 27, 2020

On closer examination, this does not actually appear to be a bug with Lind, or with anything at all for that matter.
I had a version of ls that I wrote myself for a class that worked without issue (no newlines printed), and after that I tested coreutils dir, which also did not separate entries with newlines.
I read through the ls source code and managed to track down the issue (or at least what I think the issue is) to the fact that ls only bothers formatting multiple entries per line if it's outputting to a terminal. You can see this behavior by seeing that ls | cat has only one entry per line even when ls has many. Within Lind, the environment does not look like a terminal to the called process (because it is not, and this is not behavior we will want to change likely), and thus any calls to tcgetgrp if that function is even implemented in the first place will fail.
For those that want standard terminal ls style within Lind, they can specify the -x flag, and also specifying -w and the number of columns they want the output to format to helps, as the default is 80, which might not look the best on every size of terminal.
This issue is being closed as it was solved with the mega merge and any further differences are not bugs.

@jesings jesings closed this as completed Jul 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants