Many accusations that a cat is useless are technically wrong as well as obnoxious. They typically neglect the fact that unix is an interactive programming environment and shell programs are often composed incrementally. This is easiest to do left-to-right. And in scripts, redundant commands can make pipelines easier to read, so they aren’t useless.
Recently I have been comparing a collection of source trees. I start off by working out which subset of files I am interested in, eventually resulting in a command like
ls ~/path/to/repo/subdir/*glob*
Then I operate on those files with commands like
ls ~/path/to/repo/subdir/*glob* | xargs wc -l
Which might seem like a useless use of ls and a useless use of xargs, but I can uparrow to find a previous instance of the analysis, ctrl-k to chop it off the end of the command line, and ctrl-y to append it to the latest ls command. This still works when the analysis is a multi-stage pipeline.
You’re neglecting the fact that I was using unix as an interactive programming environment and my shell programs were composed incrementally. I wrote that I looked at the output of ls first, so of course I knew the rest of the pipeline would work safely. I wrote the ls commands before I knew I would need more automation, so it was much more convenient to append an xargs (which I could copy and paste) than to edit half a dozen ls commands.
On a multi-user machine /tmp is shared. For downloads I would prefer some world-unreadable directory. Though I don’t even know what are the recommendations for things like that nowadays. On Linux there’s /run/user/<uid>, maybe this one? Does xdg have any dir for “user’s temp files”?
I know you’re replying to the last question of the parent comment, but, for downloads, if using XDG user directories, might as well use XDG_DOWNLOAD_DIR.
All my home systems are configured with NixOS and have users for everyone that might need to use them, so kind of yes.
But my PoV here is about doing things right w.r.t. security “and just in case”. If you have a system daemon that runs as a separate user, and it’s compromised, you don’t want it to snoop/modify your downloads etc.
I think that’s a bad place for downloads, since the spec says
Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.
Practically speaking, on many distros this directory is a tmpfs a few GBs or so in size, so you do actually run into the size limit, it’s not just a theoretical thing.
On my client machines, I create ~/tmp/ and use that as a location to download, unzip source bundles when I only need a single file, throw a clone of a project for a comparison. I have it set up as a ram disk with a 7 day retention so it works more or less like tmp. Additionally, I set the noexec bit on the directory which makes it a better place for stuff that I just want to dig through.
A huge amount of the stuff that I bring onto my box comes through the ~/tmp/ folder first, and after looking at it and deciding I need it for longer I will move things to a disk some where.
I realized at some point that there’s a lot of stuff I know I’d toss in 2 hours but I also didn’t want to put it in actual tmp because it’s shared and I don’t want to mess with permissions or deleting it later.
Many accusations that a cat is useless are technically wrong as well as obnoxious. They typically neglect the fact that unix is an interactive programming environment and shell programs are often composed incrementally. This is easiest to do left-to-right. And in scripts, redundant commands can make pipelines easier to read, so they aren’t useless.
Recently I have been comparing a collection of source trees. I start off by working out which subset of files I am interested in, eventually resulting in a command like
Then I operate on those files with commands like
Which might seem like a useless use of ls and a useless use of xargs, but I can uparrow to find a previous instance of the analysis, ctrl-k to chop it off the end of the command line, and ctrl-y to append it to the latest ls command. This still works when the analysis is a multi-stage pipeline.
I absolutely agree with your point, but not with your example. Not because it’s useless - it isn’t - but because parsing ls can be dangerous.
I often build my pipeline with a short
for-loop in zsh instead:Exchanging
wc -lfor echo (or even cat) here allows for much of the same flexibility as in your example :)You’re neglecting the fact that I was using unix as an interactive programming environment and my shell programs were composed incrementally. I wrote that I looked at the output of ls first, so of course I knew the rest of the pipeline would work safely. I wrote the ls commands before I knew I would need more automation, so it was much more convenient to append an xargs (which I could copy and paste) than to edit half a dozen ls commands.
On a multi-user machine
/tmpis shared. For downloads I would prefer some world-unreadable directory. Though I don’t even know what are the recommendations for things like that nowadays. On Linux there’s/run/user/<uid>, maybe this one? Doesxdghave any dir for “user’s temp files”?XDG_CACHE_HOME would be the closest match.
I know you’re replying to the last question of the parent comment, but, for downloads, if using XDG user directories, might as well use
XDG_DOWNLOAD_DIR.On macOS
$TMPDIRis a per user location unlike/tmp– although I suspect fewer macs are shared than Linux systems.This makes me curious. Do you do a lot of work like described in the article on a multi-user machine?
All my home systems are configured with NixOS and have users for everyone that might need to use them, so kind of yes.
But my PoV here is about doing things right w.r.t. security “and just in case”. If you have a system daemon that runs as a separate user, and it’s compromised, you don’t want it to snoop/modify your downloads etc.
There’s
$XDG_RUNTIME_DIR, which is usually/run/user/<uid>https://specifications.freedesktop.org/basedir-spec/latest/#basics
I think that’s a bad place for downloads, since the spec says
Practically speaking, on many distros this directory is a tmpfs a few GBs or so in size, so you do actually run into the size limit, it’s not just a theoretical thing.
On my client machines, I create ~/tmp/ and use that as a location to download, unzip source bundles when I only need a single file, throw a clone of a project for a comparison. I have it set up as a ram disk with a 7 day retention so it works more or less like tmp. Additionally, I set the noexec bit on the directory which makes it a better place for stuff that I just want to dig through.
A huge amount of the stuff that I bring onto my box comes through the ~/tmp/ folder first, and after looking at it and deciding I need it for longer I will move things to a disk some where.
I realized at some point that there’s a lot of stuff I know I’d toss in 2 hours but I also didn’t want to put it in actual tmp because it’s shared and I don’t want to mess with permissions or deleting it later.
Not sure building and deploying with git worked as intended in this case 😅
works here