Better command line option handling

[phil-s]

Note, due to how Emacs parses options, some options passed to e2ansi-cat is parsed by Emacs. Most notably, passing the option --help to e2ansi-cat displays help for Emacs itself.

You can fix this, via the -- argument to Emacs.

There's a good overview in this article:

http://www.lunaryorn.com/2014/08/12/emacs-script-pitfalls.html#processing-command-line-arguments

With everything combined, you end up with this:

#!/bin/sh
":"; exec emacs --quick --script "$0" -- "$@" # -*- mode: emacs-lisp; lexical-binding: t; -*-

(message "Hello: %S" argv)
(kill-emacs 0)

Where the -- means Emacs doesn't try to interpret the options it recognises, and the explicit kill-emacs ensures that Emacs doesn't try to visit any remaining arguments as files (you can also set argv to nil, but it's cleaner to exit rather than letting Emacs continue to do things).

[Lindydancer]

Hi!

Interesting -- I didn't know about the "--" option. I will take a look at at and see if it something I can use.

When I wrote e2ansi, I also wrote a suggestion on how to fix this on the Emacs side, by adding a new option to do all what Sebastian suggested. I haven't posted it to emacs-devel yet since I currently don't have the time I would need to work on it or even to participate in the follow-up discussion in a meaningful way.

Personally, I believe that elisp could be an excellent tool for writing batch scripts -- when it comes to processing text elisp is way better than any other language. However, having to resort to "sh" hacks to get it to run properly doesn't help its cause.

Thanks for the suggestion.

-- Anders

On Thu, Jun 9, 2016 at 2:49 AM, phil-s notifications@github.com wrote:

Note, due to how Emacs parses options, some options passed to e2ansi-cat is parsed by Emacs. Most notably, passing the option --help to e2ansi-cat displays help for Emacs itself.

You can fix this, via the -- argument to Emacs.

There's a good overview in this article:

http://www.lunaryorn.com/2014/08/12/emacs-script-pitfalls.html#processing-command-line-arguments

With everything combined, you end up with this:

!/bin/sh

":"; exec emacs --quick --script "$0" -- "$@" # -- mode: emacs-lisp; lexical-binding: t; --

(message "Hello: %S" argv) (kill-emacs 0)

Where the -- means Emacs doesn't try to interpret the options it recognises, and the explicit kill-emacs ensures that Emacs doesn't try to visit any remaining arguments as files (you can also set argv to nil, but it's cleaner to exit rather than letting Emacs continue to do things.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Lindydancer/e2ansi/issues/5, or mute the thread https://github.com/notifications/unsubscribe/ADBjQBQLmlwxy1JZV3sxOon8t9tjyuYTks5qJ2MGgaJpZM4Ixivz .

[phil-s]

FWIW the sh hack is a matter of script portability, and not really Emacs' fault. See http://stackoverflow.com/a/6259330 for details.

[Lindydancer]

Hi!

In my opinion, it's Emacs fault for not providing options to make this work in a normal unix environment. Ruby, Perl, and Python do, so it's not rocket science.

My idea (which I haven't posted about yet) is to add a new command line option to Emacs, say "--SCRIPT", that would imply "--script", "-Q", and "--". That way, an elisp script could start with:

#!/usr/bin/emacs --SCRIPT

All remaining arguments (including --help) would be passed to the script, so there would be no need for a "sh" wrapper.

Unfortunately, the little time I have for Emacs I've decided to spend on other things, but it's on my TODO list.

-- Anders

On Thu, Jun 9, 2016 at 7:44 AM, phil-s notifications@github.com wrote:

FWIW the "sh hack" is a matter of script portability, and not really Emacs' fault. See http://stackoverflow.com/a/6259330 for details.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Lindydancer/e2ansi/issues/5#issuecomment-224805291, or mute the thread https://github.com/notifications/unsubscribe/ADBjQGOB0oUtjUWAOMQxZOEf1ZnIBLXHks5qJ6hYgaJpZM4Ixivz .

[phil-s]

Ah, I see. Another option would be an alternate executable name (say, elisp). That would make #!/usr/bin/env elisp possible on any system, as #!/usr/bin/env emacs --SCRIPT still requires > 1 argument to the shebang executable.

If in addition it would (kill-emacs 0) by default after evaluating the script, and maybe manage stdout/stderr output in a more friendly fashion, that would certainly tick a lot of boxes.

[Lindydancer]

Ah, I see. Another option would be an alternate executable name (say, elisp). That would make #!/usr/bin/env elisp possible on any system, as #!/usr/bin/env emacs --SCRIPT still requires > 1 argument to the shebang executable.

It depends on if you are using "env" or not.

The shebang system handles one argument so #!/usr/bin/emacs --SCRIPT work (in this case "--SCRIPT" is passed to Emacs). The problem is with two arguments, #!/usr/bin/emacs --alpha --beta Here, one argument "--alpha --beta" is passed to Emacs, which clearly doesn't work. This mean that, unfortunately, #!/usr/bin/env emacs --SCRIPTS doesn't work.

I really like your idea with a separate executable, "elisp", since it would work with "env". Also, it would allow a user to simply type "elisp myscript" just like one can with "ruby myscript". In fact, it would be trivial to write using a shell script for unix and a bat file for windows.

While we're on the subject. Other things that I miss, to make Emacs an even better scripting environment, is a standard option handling package (like Ruby:s optparse) and functions to easily read the site and user config files.

-- Anders