341–350 of 399 posts
Earlier quoted context omitted.
Ha! My trick is to ln -s a b then look at the link with ls -l, then remove my garbage! Your way is much better.
I just do it the one way, get the error that the destination already exists, then swap them.
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
In the old days there was just 'man ln'
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
Here's how I finally memorized it: ln has a 1-file-argument invocation, so ln -s ../../a_fine_file will create a symbolic link to that file under the current directory and under the "a_fine_file" file name. The single argument case has to have the file you want to link to as input. That generalizes nicely as the 2-file-argument invocation maintaining the logic.
Earlier quoted context omitted.
There's a small list of companies I'd do a, "Take home test," for. In my experience, most companies that ask for it are looking for free labor.
I've never done a take home test that produced anything that could have been vaguely useful for the interviewing company. Usually the problems are pretty artificial.
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
$ tldr ln
ln
Creates links to files and directories.
- Create a symbolic link to a file or directory: ln -s path/to/file_or_directory path/to/symlink
- Overwrite an existing symbolic to point to a different file: ln -sf path/to/new_file path/to/symlink
- Create a hard link to a file: ln path/to/file path/to/hardlink
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
Same here. Its one of those things that after almost 20 years, I should remember. But it just does not go in. It becomes interesting when junior programmers are watching how I do something and I end up googl'ing things that they know. I use the excuse that it fees up more space for other more interesting stuff, a bit like some execs just ware T-shirt and jeans to reduce the number of things to distract them in the mo…
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
It finally clicked with me when I read about it as ln -s real fake Real is always better than fake, real comes first.
On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.
I think of it like `cp`. Source to destination, where destination is the soft link. so it's like copying a file somewhere but instead of a copy you're making a link
The real question I have left: why is this so intuitive for cp, but completely counterintuitive for ln?
I wonder if is because we think of how we would follow the link.
Earlier quoted context omitted.
I think "zip" breaks this rule.
That's because with zip (and tar, and other archivers) you can have multiple items to move to a destination archive. You can also do that with cp and mv if you need to, using `-t`. `cp -t .dotfiles/ .nanorc .bash*`. Generally more useful when you want to move a bunch of files around.
Zip does indeed break the 'rule', but this is not an excuse, cp and mv manage just fine with:
in in in in [...] out