Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking ls -l

lemis.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Hacking ls -l

#71

Post by EdiX »

jrockway wrote: post #65
Evbn wrote: post #49

Earlier quoted context omitted.

That warning seems like a nasty hack anyway, if the compiler can't inline a local when running safety checks. It is super scary that the compiler appears to be using a different constant from printf for its format checker, that shows it probably isn't using a pattern supplied by printf.

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.

Re: Hacking ls -l

#72

Post by sendos »

taf2 wrote: post #42
dalke wrote: post #19

Earlier quoted context omitted.

When I use your sed transformation on one of my directories, I see entries like: drwxr-xr-x 1,653 dalke admin 56,202 Mar 5 2,012 pubchem -rw-r--r-- 1 dalke staff 59,252 Nov 16 2,011 pubchem_10,000.fps.0.9.cluster I don't want to see the year written "2,012", and the file name is 'pubchem_10000" not "pubchem_10,000".

this should fix that. ls -l | sed -e :a -e 's/\s\(.*[0-9]\)\([0-9]\{3\}\) /\1,\2 /;ta' correction: sorry it will only fix the modifications to the filename - the year is still broken.

The following modifies only the file size:

  ls -l | perl -pe 'while(s/^((\S+\s+){4})(\d+)(\d{3})([^\d].*)?$/$1$3,$4$5/){}'

Re: Hacking ls -l

#73

Post by vinkelhake »

jrockway wrote: post #68
TwoBit wrote: post #66

Earlier quoted context omitted.

The printf ' format specifier is not Standard C. It's in neither the C99 Standard nor the new C11 Standard. So it's not actually valid, and it's a coincidence if it happens to work with your Standard Library. Consider that the compiler generating that warning knows only Standard C, and in fact you could be pairing it with any C library, including those that are strictly conforming and don't support the ' extension.

You're arguing that the GNU C Library is incompatible with the GNU Compiler Collection? (In the example, he's compiling ls with the -std=gnu99 flag, which means he's targeting GNU, not C99 or C90 or C11 or POSIX or any other standard.)

The printf(3) manpage now says: "Note that many versions of gcc(1) cannot parse this option and will issue a warning."

FWIW, GCC 4.7.2 parses the format string without warnings.

Re: Hacking ls -l

#74

Post by DanBC »

memset wrote: post #9

Guys! 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 it's hard to grok what the code actually does vs what it should do.

Re: Hacking ls -l

#75

Post by cjg_ »

dsr_ wrote: post #29

Now let's consider software lifecycle in a large context: longevity of forks. If he doesn't send the changes off to upstream, and make a case good enough for them to be approved, then all this dooms him to maintaining his fork on all the platforms where he wants it until he gets sick of it or convinces someone else to do it for him.

FYI, Greg Lehey is a longtime FreeBSD committer.

Re: Hacking ls -l

#76

Post by chris_wot »

thaumasiotes wrote: post #6

Surely the appropriate option character for this new, human-readable output is "-h". Makes you wonder whether anyone ever considered the problem before...

Human readable form in bytes? I thought it you had a file greater than a megabyte hen it shows in MB? What if you want to read it in bytes with the thousands separator?

Re: Hacking ls -l

#77

Post by lelf »

jrockway wrote: post #25

Most annoying is that gcc warns about perfectly valid and logical code. That causes people to ignore warnings, and before you know it, you have a piece of software that has more warnings than lines of code. Alternatively, when you cleverly figure out how to work around the warning, like the author does, you now prevent that rule from triggering even when it's right. Clearly a better unit test is needed.

> Alternatively, when you cleverly figure out how to work around the warning,

Or just read the docs (it should be "%'*jd "). Then no warnings. (IIRC ' is in C99 and -std=gnu99 targets c99 + gnu extensions.)

The same story with the rest. Two ways of doing things — learn & think and just do it right or twiddle until it seems to likely maybe work (possibly). The article is about the latter. Plus "blame the compiler".

Re: Hacking ls -l

#79

Post by chris_wot »

guylhem wrote: post #36
memset wrote: post #30

Earlier quoted context omitted.

Sure, this is fair. I tend to use "hacking" to mean "tinkering", and it could be said that I have a fairly loose usage of the word. To me, this article gets to the crux of what I find particularly delightful about hacking (tinkering?): unraveling layers of complexity underneath. I feel like I have a little better understanding of what's happening when I punch in `ls`, and I think that particular delight and knowledge…

I can totally agree with calling that tinkering - and also that it is interesting, if only (due to my diverging opinion on the merits of the approach) as a warning tale about how far one should go to try and fix a problem. But, just like you, I consider that not newsworthy to hackers, yet at the moment it is the #1 item on HN and it kinda makes me sad especially because of the threshold - the idea that some people do…

In what way is this not hacking?

Re: Hacking ls -l

#80

Post by dalke »

sendos wrote: post #72
taf2 wrote: post #42

Earlier quoted context omitted.

this should fix that. ls -l | sed -e :a -e 's/\s\(.*[0-9]\)\([0-9]\{3\}\) /\1,\2 /;ta' correction: sorry it will only fix the modifications to the filename - the year is still broken.

The following modifies only the file size: ls -l | perl -pe 'while(s/^((\S+\s+){4})(\d+)(\d{3})([^\d].*)?$/$1$3,$4$5/){}'

Yes. So long as you only want to modify ls -l. And don't care about column alignment. The original author wants output to look like:

    -rw-r--r--  1 root  wheel  16,596,907,252 24 Dec  2009 boskoop.disk0.bz2 
    -rw-r--r--  1 grog  wheel   4,173,914,809 20 Jul  2006 boskopp.tar.gz
With your perl one-liner on my directory I get mis-aligned columns:

    -rw-r--r--     1 dalke  staff  3,236,397,056 Sep 13  2011 pubchem.fps
    -rw-r--r--     1 dalke  staff   712,181,172 Sep 13  2011 pubchem.fps.gz
That's ugly. It should be:

    -rw-r--r--     1 dalke  staff  3,236,397,056 Sep 13  2011 pubchem.fps
    -rw-r--r--     1 dalke  staff    712,181,172 Sep 13  2011 pubchem.fps.gz
Post reply on HN