Man, this sounds like every change I try to make to "legacy" code. There's so much debt and smell. I find it very, very hard to leave alone.
Hacking ls -l
81–90 of 93 posts
Re: Hacking ls -l
#82Man, such fragile stuff. Why not code a function yourself that turns a number into a string representing it decimally with the commas every three digits. I normally like and use good library functions and standards, but if they're that fragile and depend on your environment then no thanks.
not everyone uses commas to separate their number groupings. his solution will work for any locale.
Yes, in my country we use spaces to separate thousands and "," is used for what the decimal point does in the US. In my handwriting I use that notation.
However, from a computer, I (and I'm certain I'm not the only one) actually expect it to output the US notation.
I'd much rather have a computer always output the same format (and that happens to be the US format), than try to be smart with locales, when the end result is that some things will do this, others that. Makes stuff harder to use, and when programming, harder to parse.
I've once had to touch Excel on a Windows machine configured for a non-US language, and it refused to import a CSV file that had commas, even though CSV means comma separated values. It required semicolons due to the locale settings of Windows. This stuff should not happen. A CSV is meant for computers, and to be interchangeable, not to use different types of commas and refuse to work with other types depending on user locale settings...
Of course, when publishing or printing, that's a whole different matter, and there it better get the locale of your country perfect. But this here was about output in the console, which is often meant as input of other scripts etc...
Re: Hacking ls -l
#83i always use one hack for ls. alias lsd="ls -ltrF | grep ^d" This way, I quickly run lsd to only look for directories.
That's funny, I also have an alias for lsd which does this. But you can do it without grep: lsd='ls -d */'
Re: Hacking ls -l
#84I enable this for GNU ls like: alias ls="BLOCK_SIZE=\'1 ls --color=auto" The above is a bit hacky and not very UNIXy as it's lumping more logic into ls, rather than splitting out into functional units. Number formatting being a very common requirement, I've proposed a design for a new numfmt GNU coreutil http://lists.gnu.org/archive/html/coreutils/2012-02/msg00085... which would be used like: ls -l | numfmt --field=5…
Why not
alias ls="ls --block-size=\'1 --color=auto"Re: Hacking ls -l
#85FYI, there is no need to change GNU ls to get that behavior. You can make it use your locale's separator with either the --block-size="'1" option or by setting the LS_BLOCK_SIZE envvar to that same string:
$ LC_ALL=en_US.UTF8 ls -og --block-size="'1" .
-rw-------. 1 5,145,416 Oct 5 16:44 A
-rw-------. 1 5,137,692 Oct 4 14:37 B
-rw-------. 1 5,147,168 Oct 8 07:52 C
info coreutils 'block size'Re: Hacking ls -l
#86Earlier quoted context omitted.
I guess people can be very different in this respect. I really need the full number (or at least all of the numbers in the same unit) to be displayed. I don't find the 'human' format helpful at all when looking at ls output.
It just depends what info you desire. I typically use "ls -lh" to quickly find large files to clean up to recover disk space.
I use "du -h -d 1|sort -h" for this because large files may be nested in directories and ls doesn't display the size of content directories (as far as I know). The output is sorted. Note that the "-d" flag for "du" doesn't work with all versions, but there were similar flags on all systems.
Re: Hacking ls -l
#87Guys! The point of this article is not to prescribe the only method of displaying human-readable file sizes. Obviously one could use `ls -lh`; the author clearly demonstrates that he is willing and able to read man pages to find answers. Rather, this is a pretty interesting look into what it actually entails to make what ought to be a very simple and straightforward change. It turns out that these simple changes are…
> It turns out that these simple changes are hard! Not just in identifying the piece of code to modify, but that man pages are often incomplete or unclear. This is a great shame. I like OpenBSD's approach to man pages - incorrect documentation is a bug and can be as severe as a bug in code; correct documentation is important. Fixing up man pages is something that non-technical volunteers could help with, except when…
> Fixing up man pages is something that non-technical volunteers could help with
Another problem with that is that most tools used in this process are made with technical users in mind. A lot of people can expand documentation, but sending manpages patches in a bug tracker is a technical step.
Re: Hacking ls -l
#88Earlier quoted context omitted.
> It turns out that these simple changes are hard! Not just in identifying the piece of code to modify, but that man pages are often incomplete or unclear. This is a great shame. I like OpenBSD's approach to man pages - incorrect documentation is a bug and can be as severe as a bug in code; correct documentation is important. Fixing up man pages is something that non-technical volunteers could help with, except when…
> Fixing up man pages is something that non-technical volunteers could help with Another problem with that is that most tools used in this process are made with technical users in mind. A lot of people can expand documentation, but sending manpages patches in a bug tracker is a technical step.
If one was so non-technical as to be incapable of using diff and a bug tracker, perhaps they shouldn't be writing manpages.
Re: Hacking ls -l
#89Earlier quoted context omitted.
Yes to both points. I haven't read the source code, but this feels like a case of code-oriented-programming instead of data-oriented-programming. In other words, they write printf twice: once in the C library, and once in the warning system. A more careful programmer might write both in terms of a ruleset that's declared a single time. (Or they did that and it's just a bug somewhere.)
Compiler and standard library are two separate codebases, in fact gcc gets routinely used with standard libraries other than GNU's. Reimplementing printf parsing probably is the cleanest solution.
No reason that glibc can't include a validate_format_string routine to be run at compile-time by gcc. There are already so many conditional compilation sections in both codebases that another #ifdef GNU in gcc isn't going to hurt anyone :)
Re: Hacking ls -l
#90Earlier quoted context omitted.
It just depends what info you desire. I typically use "ls -lh" to quickly find large files to clean up to recover disk space.
I use "du -h -d 1|sort -h" for this because large files may be nested in directories and ls doesn't display the size of content directories (as far as I know). The output is sorted. Note that the "-d" flag for "du" doesn't work with all versions, but there were similar flags on all systems.
I don't usually have access to a version of "sort" that supports the "-h" flag.