13 ms·
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 t
by aloknnikhil 7y ago
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.
- reginaldo 7y agoHere'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.
- munificent 7y agoThank you, this is really helpful.
- aloknnikhil 7y agoInteresting. Thanks, that's helpful. It's also a necessary approach for using relative paths as targets when you refer to the current directory to add the link in.
- psutor 7y agoThat's how I memorized it too! Really struggled with it until I started thinking of it that way.
- Noumenon72 7y agoWhat do you all use symbolic links for so much that you would need to memorize it?
- throwaway744678 7y agoHa! 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.
- TACIXAT 7y agoI just do it the one way, get the error that the destination already exists, then swap them.
- skzo 7y agoMe too, I was starting to think I was the crazy one after reading the other comments :)
- hanspeter 7y agoI think most people just feel this is risky. What if you overwrite your file? If it was a cp command, that's what would happen.
- account42 7y agoExcept if b is a directory, then ln -s a b will create a symlink at b/a which points to a.
- taftster 7y agoYup, exactly. I always use the form: ln -s ../../a_fine_file . With the added '.' at the end. That way, I can remember to change the period out if I don't want the same name (or if I'm linking in the same directory).
- autoexec 7y agoand now I've just memorized it myself. Thanks!
- vehementi 7y agoSounds like you're making bold assumptions about people's beliefs about whether the extra argument would go before or after the existing argument :)
- anilakar 7y agoI use a similar rule for those git commands that either take one or two branch names. The latter one must obviously be the current branch by default.
- nikconwell 7y agoA guy in the office always remembers it as remembering that wedding saying - something old, something new, something borrowed, something blue. Whenever he did a symlink he would always say out loud something old, something new, ... That has stuck with me as well for all these years so I've never needed to figure out which was which, I always just knew it.
- the8472 7y agoI always type ln -sT ..., which then helps me remember which one is the target of the link.
- miclol 7y agoI used to Google that a lot. But now I make an analogy with "cp", the second argument being the file that is been created (the simlink in this case)
- justmyname 7y agoI have remembered the order of arguments since I figured out that the second argument is optional. So the link name is of course optional, not the original file's one.
- deleted 7y ago[deleted]
- mlaretallack 7y agoSame 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 morning so that can concentrate on the important things.
- asdffdsa 7y ago"it fees up more space for other more interesting stuff" I see you take a similar approach to spelling
- mlaretallack 7y agoYep.
- uhhyeahdude 7y agoYour punctuation choices are also executive level.
- taneq 7y agoThere's a reason for the saying "the master has forgotten more than the journeyman has ever learned." :P
- snippyhollow 7y agoIt is like `cp`.
- loosescrews 7y agoIt isn't just like `cp`, on some systems `ln` is just a symlink to `cp`! `cp -s` does the same thing as `ln -s`, although the other flags are generally different.
- dev_dull 7y agoI believe it's a specific POSIX standard that CLI tools are always in the same order: source -> destination[1] ln, cp, mv, most everything will always follow this pattern. https://www.gnu.org/software/swbis/sw.html#o-Explicit-File-Definition https://www.gnu.org/software/swbis/sw.html#o-Explicit-File-D...
- freetonik 7y agoWhat came first: the file or the symlink? Of course the real file came first! Mnemnic that helps me: IN SYMLINKS, REAL FIRST! ln -s REAL_FILE link_name
- deleted 7y ago[deleted]
- wereHamster 7y agoI know of two different ways to remember: 1. Same as mv: `mv REAL_FILE link_name` 2. The second argument is optional. Therefore, the first argument must be the real file, and the second the link name. It does not make sense to omit the real file.
- huherto 7y agoThis. Same as mv AND cp.
- inimino 7y agoTwo minor points: They are both real files. The symlink may be created first. "Source" and "target" are confusing names because the target of the ln command is the file it creates, which is the symlink that points to the source file, which is the "target" of the symlink in an intuitive sense. The mnemonic works because it matches mv and in that case the file that exists must obviously come first. In ln without -s the file also must exist, which makes perfect sense. So it's easy enough to remember if you understand what the ln semantics are and don't get hung up by the source and target jargon.
- tiborsaas 7y agoI still couldn't do it on the command line, probably cheating, but Midnight Commander shortcut is CTRL-X-S :)
- flatline 7y agoI remember it as FROM source, TO target, so the real file comes first
- cos2pi 7y agoI'm the same way with scp, I never remember the order and then it changes if you're uploading or downloading. Also, an obligatory xkcd: https://xkcd.com/1168/ https://xkcd.com/1168/
- dllthomas 7y agoI don't understand where the confusion is with scp. It's just like cp, except you have a syntax for making some of the arguments remote. It doesn't change the order, it always does semantically the same thing of moving something(s) somewhere. This is not to criticize - we all have places our mental models break down unexpectedly. I'm just interested in how that's happening.
- heavenlyblue 7y agoI find scp really easy. rsync, on the other hand, is like tar to me.
- shiftpgdn 7y agoEasy way to remember extracting with tar is "eXtract Zee Files" -xzf.
- efreak 7y agoI no longer have issues with tar since I found out that most systems I use don't need the compression format anymore, and are happy to figure it out themselves. Not sure if it works with compressing or not (I generally use 7z or zip), but you can just `tar -x[v]f` on anything, regardless of file extension, and tar will extract anything it supports.
- dmoy 7y agoGiven the number of things that use different source vs destination with the same type, I just have trained myself to always look it up, even if I am 99% sure I remembered it correctly, because holy shit when you get it wrong sometimes it's bad. softlink dest <- src file cp src -> dest std::memcpy dest <- src java arraycopy src -> dest golang io.Copy dest <- src etc etc I'm only 80% confident I didn't make an error in the above 5 examples...
- EliRivers 7y agoIntel assembly: mov dest, src AT&T assembly: mov src, dest Whenever I'm debugging at the assembly level I have to just write down the appropriate one on a piece of paper in front of me.
- dmoy 7y agoat least arm and mips both match x86 (right? unless I forgot. probably I forgot, it's been over a decade)
- saagarjha 7y agoI've heard that C's src/dest parameter order is supposed to match assignment.
- Barrin92 7y agoi've personally given up on this after googling it a dozen times and now i just cd into the target directory first and omit it
- elviejo 7y agoI couldn't remember also. The way I finay did it was to memorize 'ln -s -T' -T stands for target that way... I know the next thing must be the target then the source.
- deleted 7y ago[deleted]
- methehack 7y agofwiw, I always say outloud in my head "thing that exists first" -- but I did need a mnemonic. Somehow I didn't realize it was just cp semantics.
- jdc 7y agoFor simple shell commands like this, tldr is really handy. https://tldr.sh https://tldr.sh
- deleted 7y ago[deleted]
- jnurmine 7y agoMy memory aid is "link file as linkname".
- iforgotpassword 7y agoThere are some clever tips here how to remember. Ages ago I struggled too so for half a day I just kept repeating the words "ln target linkname" in my head. Anyone else?
- jplayer01 7y agoI feel like a lot of this stuff is rote memorization that we shouldn't be so eager to demonize. The medical profession has you memorizing effectively random shit for years and that's fine. But in our industry, we think we should just magically remember stuff we enter once in a blue moon, and if not, who cares, just Google for it. It bothers me. And it's something I've increasingly turned to flash cards for. I'm tired of googling that command I used once 3 months ago but would be insanely useful right now.
- hyperdimension 7y agoThis is how I remembered it: Look, it's just like ''cp'', except you're making a symlink, not a copy.
- ChuckMcM 7y agoIt bothered me as well, my mnemonic became "link to <this target> using <this link name>"
- 725686 7y agoI totally get that you don't remember what goes first, it happens to me with tons of commands... but googling it? Why don't you just execute the command and see if it worked?
- parliament32 7y agoHonestly I gave up memorizing when I realized you can just omit the second parameter. ln -s /the/real/thing will create a symlink in your current directory with the same name.
- soulofmischief 7y agoThe infuriating thing is that Windows' mklink does it the other way around... link, then target. It took me years to stop RTFM every single time I'd user mklink/ln
- OJFord 7y agoThis is used to really confuse me too, but now I can't remember why, because everything's the same: touch <destination...> $EDITOR <destination...> mv <current...> <destination> cp <current...> <destination> scp <current...> <destination> mount <current> <destination> The place you're putting something is last in each case; we can even include everything that doesn't modify its location. All I can think of that breaks the rule is `rm`, `unlink`, and `umount`. But they're hardly gotchas, and they're not reversing arguments they just don't have a 'destination'.
- meow1032 7y agoI think "zip" breaks this rule.
- efreak 7y agoThat'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.
- OJFord 7y agoThe `...` in my post above was to indicate that. Zip does indeed break the 'rule', but this is not an excuse, cp and mv manage just fine with: in in in in [...] out Which is why I said the 'last' rather than 'second'.
- hibbelig 7y agoZip is a DOS tool, so I’m not so surprised it’s not following Unix conventions...
- latortuga 7y agoIt finally clicked with me when I read about it as ln -s real fake Real is always better than fake, real comes first.
- taneq 7y agoWorks for typedefs too.
- unoti 7y ago> how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first Remember it like this: It's the same syntax as "cp". To copy a file you use "cp source dest". It's the same for ln: "ln -s source dest"
- rohit2412 7y agoI always think of links as pointing from source to destination. Your way would break that intuition for me. It would be the source of the address and the destination for the address to be copied to.
- unoti 7y agoI understand fully; that’s also how I thought of it for years and why I couldn’t ever remember it. But if you think about it like copying a file it’s easier to remember. And it is like copying a file— it’s copying a reference to a file.
- bonoboTP 7y agoRemember it like this: just as in cp, the file that already exists comes first, the file/link we are creating now comes second.
- Izkata 7y agoTry taking the command a step back with hardlinks: ln source dest The association with cp makes a lot more sense then. This is how I learned it.
- Rapzid 7y agoWell, you're linking TO something and not FROM something so target seems more accurate(they are essentially pointers). I'm honestly surprised about the help confusion though: ln --help Usage: ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
- inimino 7y agoThat is the symlink target, not the ln target, which is exactly why the "target" nomenclature is confusing. Also note that not every "ln" has a "--help" or uses that help message as the output. For example, try on OS X `/bin/ln -h`.
- Rapzid 7y agoYes, it would be platform specific as the OSX ln command would not be the same program as the GNU coreutils ln program. For GNU ln at least I don't find it confusing at all particularly considering the only other option is LINK_NAME. I guess YMMV though and it seems kinda pointless to argue whether it is or is not confusing. Perhaps a poll could quantify it.
- inimino 7y agoIf "target" is used to mean two different things in the same context, it is going to confuse people! This is why naming things is hard!
- Rapzid 7y agoIn GNU coreutils ln help and man page it only ever uses TARGET to refer to the link target?
- inimino 7y agoI wasn't speaking specifically about GNU. Note though that even there you see a --target-directory, -t, -T flags that make literally no sense anymore once GNU reversed the meaning of the term.
- zikani_03 7y agoHaha, glad to see I'm not the only one who struggled with remembering this. I always refered to a task in a fabfile to remember. +1 for "follow cp or mv semantics"
- 19ylram49 7y agoI just search my shell history for that one, because I can never remember either!
- pw6hv 7y agoln -s actual link Read it somewhere long time ago, never had to look for it again :)
- eric_h 7y agoI found remembering that it's the same as `cp` is what stopped me from continuously googling it.
- inimino 7y agoReading the man page instead of Googling this will make you a better engineer, and it will also cost more of your time while you figure out what the man page is trying to say. This knowledge may save you time later, if you use it again, or not. So the advice I would give is, never Google if the answer can be found in the man page. Unless it's a tool you're unlikely to ever use again, of course.
- jplayer01 7y agoMan pages are so insufferably long and mostly irrelevant though. It's come up on HN before, I think, how if you're ever looking for anything specific like commonly used arguments and common usages, it's a complete waste of time to go through an entire man page.
- inimino 7y agoExcept that, if you think about it, every sentence in a well-written man page was put there by an absolute expert in the tool who thought you might need to know it. If you want to master your tools, it's absolutely not a waste of time to read the friendly manual. When you use a system professionally every day and refuse to read the manuals because it takes too long, and you're in way too much of a hurry, you're only hurting yourself in the long run. You're probably going to notice the time you spend reading man pages, when you just! want! to! get! something! done! And that's frustrating. What you're less likely to notice is the next five times you reach for the wrong tool, or have to go hunting around for some bubble-gum-and-twine way to do something, because you didn't previously read the man page that tells you exactly what you needed to know to do it easily and correctly.
- jplayer01 7y agoWell, no. Even if I read the damn thing, there are tens of tools I use day to day. I'm not going to remember any of it. It doesn't matter how much of an expert the author was if it's not structured in a useful way. And I've read enough fucking man pages. I've retained zero except for maybe what I ended up using. If I used it more than once. Maybe. Man pages don't tell you shit. They tell you everything and you still need to parse, interpret and analyze it because it's so ridiculously dense and there's never any guidance on actual real-world usage. Theoretically they're useful, realistically, they completely ignore everything about how human beings function. They're not written for people. Hell, I often find that while the author has managed to cram everything and the kitchen sink into it, there's so much missing from it regarding how a tool works, caveats, whatever. All these things that are crucial to actually understanding the tools you're using beyond what some flag or other does on a surface level.
- red75prime 7y agoBusybox's ln --help is straight to the point Usage: ln [OPTIONS] TARGET... LINK|DIR Create a link LINK or DIR/TARGET to the specified TARGET(s)
- wcchandler 7y agolink -s this (to) that This has to exist... but that doesn’t.
- TaylorAlexander 7y agoI search (duck duck go) for this constantly. For a couple of days last week I remembered it, but it’s always helpful to check. Some day I should see what happens if I get it backwards. Probably it will say no and that’s it. If that’s true then I can just try until it works!
- arminiusreturns 7y agoIf you google/duckduck go something more than once, I think it should be put into documentation. I have one central org file where I keep that majority of my one off questions about a tool, and these days I look there often first before man or info because I have condensed the information into something faster to parse for me. Right now my main battle is deciding to port docs like this into asciddoc(tor) or keep them in org, both being exported to html5 eventually.
- meddlepal 7y agoHah, I thought I was the only one!
- throwaway5d097 7y agoI 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
- dpwm 7y agoSame here. After adopting this approach, I haven't had to look it up since. 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.
- iandanforth 7y agoThis. "I want something here that points to there" is how I always think about it. That's why "link" on my boxes is mapped to "ln -s" with the arguments swapped :)
- hnarn 7y ago> I think of it like `cp`. Source to destination, where destination is the soft link. That doesn't make sense to me. The way I think about cp is "copy this, and put it over here". If you think about symlinks that way, you mix it up. When you say "source to destination, where destination is the soft link", that makes it more confusing for me, because if you consider the symlink that is being created as the "destination" (which at least is the intuitive way to think about it for me, but I suppose it's individual), you actually end up with: # cp [source] [destination] # ln -s [destination] [source] Where "source" is "the new thing that should be created". Since I seem incapable of getting out of this way of thinking about sources and destinations, my rule of thumb is that when creating a symlink, you always decide where it should point first. Not intuitive perhaps, but this time I've made the mistake so many times it kinda sticks.
- throwaway5d097 7y agoIf it was a hard link, I suppose my way of thinking about it would make more sense, since all hard links are as valid, pretty much the same. That is, after running ln /some/file /other/file /some/file and /other/file are hard links. So in this case ln is just copying a hard link, while afaik cp would be copying data, making a hard link pointing to the new data. In userspace? That seems to be what's happening here - https://github.com/openbsd/src/blob/master/bin/cp/utils.c https://github.com/openbsd/src/blob/master/bin/cp/utils.c This is made a bit more confusing by the differences in man pages. For GNU ln, it's shown as ln TARGET LINK_NAME, but for OpenBSD, ln source [target]. But the usage is pretty much the same?
- deleted 7y ago[deleted]
- bb88 7y agoIn the old days there was just 'man ln'
- afabisch 7y agoYes, you don't need to switch to a browser.
- taesko 7y agoI remember it by first remembering that it is possible to not provide the destination (ln /.../file) to create a symlink with exactly the same name in the current directory. So it has only 1 required argument which always has to be first.
- tejtm 7y agoit is the same as copy first `from` then `to`
- 384028345 7y agoYou might like the tldr program: $ 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
- harubbba 7y agoAll gnu command line tools are the same in this regard: SOURCE DESTINATION. ln -s src dst
- senozhatsky 7y agoI pretend that '-s' stands for "source", not "symbolic"; and source file follows -s(ource) option. IOW `ln -s A B' is `link source A to B'.
- ihaveajob 7y agoI read `ln -s A B` like "link A as B", and it tends to work with most Unix commands.
- martin-adams 7y agoAbout 15 years ago a colleague of mine at IBM had the following on their board. ln -s physical virtual I never forgot it and can see it visually in my mind. You need something physical before you can virtualise it.
- xelxebar 7y agoThinking like this, it fits the pattern of other coreutils tools: $ mv existing_path new_path $ cp existing_path new_path $ ln existing_path new_path
- fukyall 7y agoThe best way to remember it is that only the first argument is mandatory.
- neop1x 7y agoI think 'ln' as a tool which creates a symlink. And symlink is a new object, a new kind-of file. So it must be the last argument. The source is just an attribute of that symlink "file" holding the path it points to. If I want to overwrite an existing symlink "file", I simply add -f meaning force-overwrite-if-the-symlink-file-already-exists.
- bayonetz 7y agoI love the man replacement packages like tldr, bro, etc. for exactly these kinds of simple, yet easy to forget incantations.