Allow shebang usage without .nim extension

[al6x]

It's possible to make executable nim scripts with shebang and run it as ./hello.nim.

But it won't work if the file renamed into ./hello without the extension. If you run nim r hello the Nim compiler appends the .nim extension and tries to execute it as nim r hello.nim and fails because there's no such file.

Allow using nim r hello as it is, without appending the extension. As Nim executable scripts, like bin/fetch or bin/deploy looks much better than bin/fetch.nim or bin/deploy.nim.

#!/usr/bin/env nim c -r

echo "Hi"

[Araq]

Meh, filenames without extensions are a Unix design bug anyway.

[al6x]

It's for usage as command line utilities or binaries, like bin/fetch or bin/deploy, the exact kind of file is not important in such usage. It's similar as if you had to type cat.cpp somefile.txt or ping.cpp some-site.com.

@al6x that's not a good comparison - You want shebang to work with the Nim compiler without the extension for uncompiled programs, while cat or ping are both already compiled.

[al6x]

@Yardanico I can't see any difference from the user point of view. Like - when I use some android app, say uber, I don't care if it's made with Java or Kotlin or whatever else, if it's compiled or dynamically assembled with HTML and VebView. I just type in Uber the address and click Go button.

Same here, I don't care what's inside of bin/fetch or cat if it's binary, ruby or python script or C-binary or nim script or binary or bash function or whatever else. For me it's just an app that does some thing, and I don't care how it does that or how it works internally.

I'm using it for data processing scripts, and I don't understand why Nim scripts should be an unique citizen and break commonly used convention and practices and work differently from Python, Ruby, Bash and other scripts.

[c-blake]

You can get what you want already via a symlink.
file: /tmp/j.nim; contents:

#!/usr/bin/nim r
echo 123

Then symlink /usr/local/bin/j -> /tmp/j.nim from e.g. ln -s /tmp/j.nim /usr/local/bin/j as root or maybe $HOME/bin if that is in your PATH command search path. Then you can at a shell prompt run:

$ j

and get output of "123". Bonus points, you can also have a /tmp/j.nim.cfg file (or probably /tmp/j.nims, too) that contains module specific build controls such as --verbosity:0.

[c-blake]

Oh, and why you need/want a separate /tmp/j.nim.cfg or /tmp/j.nims comes from a bona fide portability problem in that how the shebang line is "split" was not given much thought - not unrelated to the proposed splitShellCmd, actually. See https://en.wikipedia.org/wiki/Shebang_(Unix)#Character_interpretation . They wanted a string that was "shell-esqu-y but not really and not fully capable" and easier than a full shell parser for the kernel to split.

Besides mere verbosity you might have defines like -d:release, -d:ssl, --threads:on, or maybe later --threads:off or any number of other things. It also is not much of an extra installation step to just make a symlink. It also works if j -> j.nim in the very same directory at least with nim r. With nim c it will get clobbered, but probably in the least confusing way possible in that your j command will do the right thing, but allow "staleness" (EDIT: i.e. if the source j.nim changes). Nothing is perfect.

Anyway, I think much like you do in terms of "command usability", but I think what Nim already does is a fine compromise solution. If you do also then perhaps you can add something to the Wiki/docs/tutorials somewhere for better discoverability.

[c-blake]

Oh, btw it is also possible to get the often popular "dash/minus sign" as a word separator for script-like programs this way via a-b-c -> j.nim or in the nim c mode to set -o:"a-b-c" in the nim.cfg.

[al6x]

@c-blake thanks for idea with symlink.

Anyway, I think much like you do in terms of "command usability", but I think what Nim already does is a fine compromise solution.

Agree, it's not a big deal, just a nice to have feature.

[juancarlospaco]

No.

[Araq]

Same here, I don't care what's inside of bin/fetch or cat if it's binary, ruby or python script or C-binary or nim script or binary or bash function or whatever else. For me it's just an app that does some thing, and I don't care how it does that or how it works internally.

Cool, good for you. But I think that treating binaries (=compilation artifacts, can be re-build) the same as source code (hopefully under the control of a versioning system) is a terrible idea.