You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Currently running
ls
through Lind gives us something likeThe 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.
The text was updated successfully, but these errors were encountered: