[PATCH 1/2] don't treat "emacs -- file" like "emacs --chdir file"

[PATCH 1/2] don't treat "emacs -- file" like "emacs --chdir file"

[Jim Meyering]

I wrote a function to edit all files modified by the most
recent git commit:

    evm() { emacs "$@" -- $(git diff --name-only HEAD^!); }

However, a few months ago it stopped working.
Since then, "--" is treated like "--chdir", and
invoking emacs like that always fails.

The first change fixes the obvious bug, assuming the intent
was to allow the 4-byte "--ch" as an abbreviation for "--chdir".
The second one fixes the more general one, allowing "--"
to work as it does in nearly every other Unix command-line program.


From 7de7a875858cc0000c6d6bc068613535f76d023f Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Sun, 24 Oct 2010 16:21:08 +0200
Subject: [PATCH 1/2] don't treat "emacs -- file" like "emacs --chdir file"

* src/emacs.c (main): The code would mistakenly treat "--"
as matching "--chdir".  Require at least "--ch" to match --chdir.
---
 src/emacs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/emacs.c b/src/emacs.c
index 70a0fae..b451821 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -829,7 +829,7 @@ main (int argc, char **argv)
       printf ("see the file named COPYING.\n");
       exit (0);
     }
-  if (argmatch (argv, argc, "-chdir", "--chdir", 2, &ch_to_dir, &skip_args))
+  if (argmatch (argv, argc, "-chdir", "--chdir", 4, &ch_to_dir, &skip_args))
       if (chdir (ch_to_dir) == -1)
         {
           fprintf (stderr, "%s: Can't chdir to %s: %s\n",
--
1.7.3.1.216.g329be


From 4af787f78d3c4ad7ea9246a0339ac642e97dadab Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Sun, 24 Oct 2010 16:22:57 +0200
Subject: [PATCH 2/2] honor the POSIX "--" end-of-options indicator

* src/emacs.c (argmatch): Treat "--" specially: as end of options,
so that one may edit a file named --version using the common idiom,
emacs -- --version.  Of course, ./--version works, too, but using
"--" is preferred in scripts because with it you don't have to
examine-and-possibly-modify each non-option argument.
---
 src/emacs.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/src/emacs.c b/src/emacs.c
index b451821..53f07f6 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -634,11 +634,19 @@ void __main (void)
    enough information to do it right.  */

 static int
-argmatch (char **argv, int argc, const char *sstr, const char *lstr, int minlen, char **valptr, int *skipptr)
+argmatch (char **argv, int argc, const char *sstr, const char *lstr,
+	  int minlen, char **valptr, int *skipptr)
 {
   char *p = NULL;
   int arglen;
   char *arg;
+  static int found_end_of_options = 0;
+
+  if (!found_end_of_options && strcmp (argv[*skipptr], "--") == 0)
+    {
+      found_end_of_options = 1;
+      ++*skipptr;
+    }

   /* Don't access argv[argc]; give up in advance.  */
   if (argc <= *skipptr + 1)
--
1.7.3.1.216.g329be

Re: [PATCH 1/2] don't treat "emacs -- file" like "emacs --chdir file"

[Chong Yidong]

Jim Meyering <jim@meyering.net> writes:

> The first change fixes the obvious bug, assuming the intent
> was to allow the 4-byte "--ch" as an abbreviation for "--chdir".

Thanks, committed.

> The second one fixes the more general one, allowing "--" to work as it
> does in nearly every other Unix command-line program.

Hmm, without this patch "emacs -- --foo" already seems to work as
expected.  Could you explain this patch in more detail?

Re: [PATCH 1/2] don't treat "emacs -- file" like "emacs --chdir file"

[Jim Meyering]

Chong Yidong wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> The first change fixes the obvious bug, assuming the intent
>> was to allow the 4-byte "--ch" as an abbreviation for "--chdir".
>
> Thanks, committed.
>
>> The second one fixes the more general one, allowing "--" to work as it
>> does in nearly every other Unix command-line program.
>
> Hmm, without this patch "emacs -- --foo" already seems to work as
> expected.  Could you explain this patch in more detail?

You're right.  With the first one, the second one is not needed.
Good call.