5 ms·
In general, composing Unix commands is a very powerful means to construct complex applications... poorly, with no real pathways to fixing their shortcomings. I
by chias 3y ago
In general, composing Unix commands is a very powerful means to construct complex applications... poorly, with no real pathways to fixing their shortcomings. I believe the traditional "Unix Way" is to gloss over said shortcomings and pretend they don't exist, and when that fails, move the goalposts and argue that they don't exist "in the real world".
For example, what combination of shell commands can I use to output the number of files in a directory?
Hint: it's a trick question, you can't.
- memetomancer 3y ago|For example, what combination of shell commands can I use to output the number of files in a directory? Hint: it probably isn't what you think it is, if it's even possible. `find . -type f | wc -l`
- jcynix 3y agoGood first attempt. But: counts two links to the same file twice. That is: touch foo; ln foo bar Is this one file or two "links" to the same file? ;-0
- bandrami 3y agoYou said files, not inodes. Those are two files sharing one inode. If you want to count inodes, specify that in the question.
- jcynix 3y agoI'm not the one who posed the question. And: file, filename, inode, ...? What's what and what's exactly to be counted?
- memetomancer 3y agothe inode is the important thing when all is said and done. It is flexible in that it can contain all the metadata needed to present a file to a process. Sometimes that metadata is a list of blocks in the filesystem. sometimes it points to another inode. I think of it like an old-timey 'card catalog'. You have a bunch of tiny drawers filled with cards. Some of the cards are big and blank spacers with a prominent tab sticking above the normal top edges (Directory). Sometimes you have a card that points to another card elsewhere in the catalog (link). Sometimes you find the details of a specific book on a specific shelf (block data). Point is, they are all cards. The comment essentially asked for a command to say 'how many cards between these two spacers'. It's a "trick" question as old as usenet to spring the distinction between link inodes and list of blocks inodes and say "Ah-HAH!! gotcha", but in reality it's a silly game of jumping levels, misdirecting semantics and prey upon the distribution of understanding in a forum for personal glory. The inode is the item, it is the card that is being counted, no matter what is printed on it. imho.
- deleted 3y ago[deleted]
- preseinger 3y agoabsent further qualifications it is two files
- chias 3y agoThis doesn't work. Try setting up a test directory as follows: touch first$'\n'file touch .hidden$'\n'file mkdir folder$'\n'. touch folder$'\n'./another$'\n'file There are two files in the folder, or three if you want to count files in subdirectories too. Your solution incorrectly outputs 7.
- JdeBP 3y agoIt isn't what I think it is? Oh. Then it must be: command ls -F directory | grep -v '[/@]$' | nl | tail -n 1 | cut -f 1 (-:
- chias 3y agoThis doesn't work. Try setting up a folder as follows: touch first$'\n'file touch .hidden$'\n'file mkdir folder$'\n'. touch folder$'\n'./another$'\n'file mkdir normal touch normal/whatever This folder has two files in it, or four if you count files in subdirectories. Your solution incorrectly outputs 3.
- JdeBP 3y agoAs clearly stated, the above is not what I think the way to do it is.
- toast0 3y agofind . -type f -depth 1 -print0 | tr -d -c '\000' | wc -c GNU find has a -printf which would probably avoid the need to use tr. Personally, two hardlinks to the same underlying storage counts as two files to me, but I understand why you might disagree. I'd bet there's something out there that could give you only the count of unique storage areas, but I don't know how that interacts with deduplicating filesystems.
- chias 3y agoNice! This wins :) I had to modify it a bit to get it to work cross-platform, but the approach does appear to be sound: find . -maxdepth 1 -type f -print0 | tr -d -c '\000' | wc -c I had originally written "Hint: it probably isn't what you think it is, if it's even possible", but after testing for a bit, I updated my comment in what was apparently a fit of hubris to say you couldn't.
- toast0 3y agoI had seen the original comment, but people are always telling me things can't be done, even though I can do them. :P
- deleted 3y ago[deleted]
- nixpulvis 3y agoMastering UNIX allows you to pull tools out of a toolbelt and adapt to the situations as the arise. No one tool should solve every job. You can happily ignore problems that aren’t relevant to the issue at hand. Two servers need to talk to each other behind a strong firewall in a private network, sure, skip complex authentication setups. Knowing how to build in layers is good engineering practice. Whereas large scale enterprise commercial solutions make money by selling you on complete solutions that force you to relearn everything their way from the ground up. Just look at how AWS has hijacked so many concepts from the modern web and trapped people into building “cloud-agnostic” wrappers to try and wrangle the mess. Still we’re mapping onto their redesigns of the same old stuff. At some level it’s unavoidable, hardware vendors need to agree on instructions after all, but when looking at the situation from a high level, it’s best to keep our ideals in mind and steer the ship so-as to find ourselves in paradise not lost in a sea of pirates. One ideal: Modularity. Promotes healthy competition. Another ideal: Simplicity is more easily achieved when modular components may be used (and tested) in isolation.