Does anyone actually use touch
for its intended purpose? Must be up there with cat
.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
The intended use of touch
is to update the timestamp right?
Yeah. It could just as well have issued a file not found error when you try to touch a nonexistent file. And we would be none the wiser about what we're missing in the world.
“Do one thing and do it very well” is the UNIX philosophy after all; if you’re 99% likely to just create that missing file after you get a file not found error, why should touch
waste your time?
Because now touch does two things.
Without touch, we could "just" use the shell to create files.
: > foo.txt
Touch does one thing from a “contract” perspective:
Ensure the timestamp of is
Systemd also does one thing from a contract perspective: run your system
Oh no.
:(
Does it do it well, though?
with this logic, any command that moves, copies or opens a file should just create a new file if it doesn't exist
and now you're just creating new files without realising just because of a typo
But this directly goes against that philosophy, since now instead of changing timestamps it's also creating files
If you touch -c
it should work I guess
We use it to trigger service restarts.
touch tmp/service-restart.txt
Using monit
to detect the timestamp change and do the actual restart command.
This is an interesting idea to allow non-root users to restart a service. It looks like this is doable with systemd too. https://superuser.com/a/1531261
Indeed. Replacing monit with systemd for this job is still on our todo list.
I sometimes use cat to concatenate files. For example, add a header to a csv file without manually copy and paste it. It’s rare, but at least more frequent than using touch.
$ cat file1 > output_file
$ cat file2 >> output_file
$ cat file3 >> output_file
I'm sorry!
That's its intended purpose - combining files together (the opposite of split
). See the first line of the man page: https://man7.org/linux/man-pages/man1/cat.1.html
what is cat's use if not seeing whats inside a file?
It is short for concatenate, which is to join things together. You can give it multiple inputs and it will output each one directly following the previous. It so happens to also work with just one input.
TIL
I never realized. Thanks!
It is to use along with split
.
e.g.
- You take a single large file, say 16GB
- Use
split
to break it into multiple files of 4GB - Now you can transfer it to a FAT32 Removable Flash Drive and transfer it to whatever other computer that doesn't have Ethernet.
- Here, you can use
cat
to combine all files into the original file. (preferably accompanied by a checksum)
I used it recently to update the creation date of a bunch of notes. Just wanted them to display in the correct order in Obsidian. Besides that though, always just used it for file creation lol
cat
Ahhhhh, fuck. I'm quite noob with linux. I got into some rabbit hole trying to read the docs. I found 2 man pages, one is cat(1) and the other cat(1p). Apparently the 1p is for POSIX.
If someone could help me understand... As far as I could understand I would normally be concerned with (1), but what would I need to be doing to be affected by (1p)?
The POSIX standard is more portable. If you are writing scripts for your system, you can use the full features in the main man pages. If you are writing code that you want to run on other Linux systems, maybe with reduced feature sets like a tiny embedded computer or alternates to gnu tools like alpine linux, or even other unixes like the BSDs, you will have a better time if you limit yourself to POSIX-compatible features and options -- any POSIX-compatible Unix-like implementation should be able to run POSIX-compliant code.
This is also why many shell scripts will call #!/bin/sh instead of #!/bin/bash -- sh is more likely to be available on tinier systems than bash.
If you are just writing scripts and commands for your own purposes, or you know they will only be used on full-feature distributions, it's often simpler and more comfortable to use all of the advanced features available on your system.
I mean, timestamps aren't really all that useful. Really just if you do some stuff with makefiles but even then it's a stretch. I did once use cat for its intended purpose tho, for a report. We split up the individual chapters into their own files so we have an easier time with git stuff, made a script that had an array with the files in the order we wanted, gave it to cat and piped that into pandoc
Touch is super useful for commands that interact with a file but don't create the file by default. For example, yesterday I needed to copy a file to a remote machine accessible over ssh so I used scp
(often known as "secure copy") but needed to touch
the file in order to create it before scp
would copy into it
Sorry, what?
I use it regularly
Creating an empty file is one of its intended purposes. Unix commands were designed as multi-purpose primitives, so they could be reused and composed to handle many different tasks. The touch command is no exception.
i use both frequently but im also a pretty dumb user
These are some weird looking dolph--- oh
Is there a command that's actually just for creating a new file?
Nope. If you open a nonexistent path and you have permissions to write to that directory, then that file is created.
I guess printf "" > file
I mean, nano filename
will work, but there's no mkfile that I can find...
$>filename
would also work, but it's not explicitly for creating a new file
most shells will accept outputting from a silent command to a file, e.g. :> foo.txt
(where :
is the posix synonym to the true
command)
How often do you actually need a blank file though? Usually you'd be writing something in the file.
I'm betting that's why none ever materialized. Most tools that can manipulate a file, can also create that file first, so there's just never been a usecase.
Right-clicking the desktop to create a new txt file in Windows feels so natural, but I can't really think of any time you'd want to create a new file and do nothing with it in a CLI.
You might if some other program checks whether that file exists and behaves differently depending on that.
But even still, what's a realistic usecase that would that involve needing a blank, unmodified file in that instance?
Same energy as Joan Cornella's comics
'Murica!
As a Linux user, that is truly magical, and beautiful.