Live data from Hacker News

I always forget the argument order of the `ln -s` command

reddit.com

91–100 of 127 posts

Re: I always forget the argument order of the `ln -s` command

#91
post #10

Does anyone know why C calls like 'strcpy' and 'strcat' are the opposite of this? strcat(target, source) strcpy(target, source) But, in SH... cp source target I feel like these things were developed around the same time, by the same community. I've always wondered if there was a reason for the different perspective.

Someone once said to "What you have, then what you want" which made ALL of these easier to remember for me. In the case of strcat/cpy I think it still follows: I have an empty string 'target' and I'd like it to be 'source'.

Re: I always forget the argument order of the `ln -s` command

#93
post #58
post #41

Earlier quoted context omitted.

tar is like that because of command lines tar [args] [one thing] [list of things] it'd be wierd if it was tar [args] [list of things] [filename] ... but i will admit i frequently make that mistake.

tar is actually tar [args] [list of things] where [args] may contain [-f filename], among other things. That is, the destination filename is an optional argument; by default tar outputs to a tape device or stdout, depending on the implementation. At least in GNU tar, the target filename can very well be specified as the last argument: tar -c foo.txt bar.txt baz.txt -f stuff.tar

good point!

Re: I always forget the argument order of the `ln -s` command

#94
post #88
post #54

Earlier quoted context omitted.

In my experience the more variable argument often comes last, presumably for easy reuse. For example... $chown user1 file1 $chown user1 file2 $ln -s file1 file2 $ln -s file1 file3 ...seems more likely than... $chown user1 file1 $chown user2 file1 $ln -s file1 file2 $ln -s file3 file2

That's the reason behind a most of the argument orders in the Haskell standard library: To ease Currying.

Why did you do that? Now I really want to implement a const and flip for text arguments :)

Re: I always forget the argument order of the `ln -s` command

#95
post #34

I also occasionally forget the -s, and really wish it was the default since I'm almost always creating a symbolic link.

Could you maybe add: alias ln='ln -s' to your .bashrc? A quick test of this in my terminal and the alias takes precedent over the ln command. Although, I guess it'd be worth doing a few tests to make certain!

Sure, but I'd rather not get bitten when I'm on a system where I don't have that alias defined.

Re: I always forget the argument order of the `ln -s` command

#96
I used to get this wrong all the time too. Mentally, I'd be thinking "ln -s source destination", where source was the link and destination was what it pointed to. Of course, that's completely backwards. 'man ln' on OSX didn't help either, since they use the terminology 'source_file [target_file]' which just re-inforced my incorrect thinking (target sounds like something that is pointed to, does it not?).

As other people have mentioned, thinking of it in terms of the files created (ala cp) has helped to learn the correct behavior. I think this is a case where some minor change in the documentation might help to avoid the whole problem.

Re: I always forget the argument order of the `ln -s` command

#97

Why don't we have better shells that give hints on these things? I'm thinking like an IDE will pop up some help text when you begin typing a function name or a recognised special word. Why doesn't the standard sh (bash for me) give me similar help, as I type "ln" it could give me a pop-up with the possible completions and then as I get to "ln -s" it could remind me with "TARGET [NAME] // will create a file named NAME…

It's mostly for historical reasons. More specifically we have restricted shell as text mode only tool, and intellisense-like features/inline help do not tend themselves neatly to line/character based output.

I think that there could be a place for a modern, more graphical orinted command-line interface. In addition to inline help it could display tables more nicely, maybe even allow proportional fonts. And while we are changing stuff, then maybe the object passing idea could be taken from PowerShell.

Re: I always forget the argument order of the `ln -s` command

#98
post #2

I used to have this problem. Then I realized that if I want to really copy a file, I type $cp file_from file_to and that $ln -s link_from link_to has a very similar effect to the cp command above. I haven't messed this up ever since.

This phrasing confused me more. `$ ln -s link_from link_to` would imply the reverse behavior. How does a symlink point from the actual file to the thing-that-looks-like-a-file-but-is-really-a-symlink? The file doesn't even know whether there are symlinks pointing to it. Applying your definitions of "link from" and "link to", this: Google http://google.com/>Google ; creates a link from google.com to the hyperlink on y…

Less ambiguously:

  cp    existing_thing new_thing
  ln -s existing_thing new_thing

Re: I always forget the argument order of the `ln -s` command

#99
post #8

My god, this thing always keeps biting me. It seems so obvious now with that cp-mnemonic. But it makes me wonder, why does everyone do it wrong in the first place?

At least for me, it's because I say in my head "link $FOO to $BAR", which must be typed "ln -s $BAR $FOO".

The problem is that you're using the wrong definition of "link". I also say "link $foo to $bar", but that puts it in the right order:

I have a folder. I want to link that folder to some other name, over yonder. " ln -s foo bar". See?

Re: I always forget the argument order of the `ln -s` command

#100
post #97

Why don't we have better shells that give hints on these things? I'm thinking like an IDE will pop up some help text when you begin typing a function name or a recognised special word. Why doesn't the standard sh (bash for me) give me similar help, as I type "ln" it could give me a pop-up with the possible completions and then as I get to "ln -s" it could remind me with "TARGET [NAME] // will create a file named NAME…

It's mostly for historical reasons. More specifically we have restricted shell as text mode only tool, and intellisense-like features/inline help do not tend themselves neatly to line/character based output. I think that there could be a place for a modern, more graphical orinted command-line interface. In addition to inline help it could display tables more nicely, maybe even allow proportional fonts. And while we a…

It could still be text-based if it uses ncurses. For instance, something like bpython: http://bpython-interpreter.org/screenshots/
Post reply on HN