Hmm, it works if I use:

shelljs.ln('-s', '/some/source/path', 'nameForLink');

It looks like ln should behave like cp: if the last argument is an existing-directory, then the link should be created inside that directory and the link name should default to the name of the thing it points to.

Concretely, it should look like this:

$ ln -s path/to/file.txt thisFolderExists
# there's a link named thisFolderExists/file.txt

$ ln -s path/to/file.txt thisDoesNotExist
# there's a link named 'thisDoesNotExist', which points to 'path/to/file.txt'

$ ln -s path/to/file.txt thisRegularFileExists
ln: failed to create symbolic link 'thisRegularFileExists': File exists

Yep, that's pretty much what I described.

One thing to mention though (which I figured out while implementing the attached pull request): The name in fact does not default to the source pointed to, but the basename you provided.

By Example:

Assume the following directory tree:

a/
└── b/
    └── c/

If we are in c/ and run ln -s . ../.., we'd expect to get a symlink named c, located inside a, pointing to c.

This is, in fact, not the case. The command will fail with ln: failed to create symbolic link '../../.': File exists.

That leads me to assume that the default name is actually the basename from the user-provided source path.

is actually the basename from the user-provided source path.

Seems reasonable. ln -s is kind of funky in that respect.