GNU bug report logs - #76322
Make ctags a thin wrapper around etags

Previous Next

Full log

Message #39 received at 76322 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76322 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76322: Make ctags a thin wrapper around etags
Date: Sun, 09 Mar 2025 12:23:33 +0000

"Paul Eggert" <eggert <at> cs.ucla.edu> writes:

> On 2025-03-06 05:31, Eli Zaretskii wrote:
>>> Date: Tue, 4 Mar 2025 10:37:05 -0800
>>> Cc: 76322 <at> debbugs.gnu.org
>>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>>>
>>> Thanks for the review. Revised patch attached, which I think addresses
>>> all the comments.
>>
>> Thanks.  This mostly worked, but I needed a few minor changes (below).
>> We should use _spawnvp, not _execvp, since the latter doesn't return,
>> so we cannot return the exit status of etags to the caller.  More
>> importantly, the counting of bytes to allocate missed the PROGRAM part
>> of --ctags=PROGRAM, so ctags would crash in weird ways.  Finally, I
>> need to include stdio.h to get the declaration of perror.  Here's the
>> patch:
>
> Thanks, I incorporated all that into the proposed patch. A couple of
> things, though. First, when _spawnvp returns -1 I assume ctags should
> call perror and exit with status 127 rather than simply try to exit with
> status -1. Second and more important, my earlier proposal violated the
> GNU Coding Standards because its behavior depended on its name.[1]

If you're referring to the previous behavior of looking for etags in the
right directory, rather than a hard-coded directory as the current patch
does, I'm not sure how the GNU coding standards prohibit that.

> Fixing the second problem simplified the C and shell code a bit. Revised
> patch attached.

But that means we hard-code the installation path for "etags" in the
"ctags" shell script/executable, which seems worse than simply depending
on the name (or going back to building two binaries) to me.
Non-relocatable builds are a pain.

It's also different from what other GNU utilities do: gunzip looks for
gzip in the PATH, for example.

> diff --git a/lib-src/ctags.sh b/lib-src/ctags.sh
> new file mode 100755
> index 00000000000..13a4320d9e9
> --- /dev/null
> +++ b/lib-src/ctags.sh
> @@ -0,0 +1,2 @@
> +#!/bin/sh
> +exec '@ETAGS_PROGRAM@' --ctags="$0" "$@"

I think this file should not be executable (and I'm not sure why it's
called "ctags.sh" rather than "ctags.in" or something similar, which
would indicate it needs to be processed to yield an executable file).

> +  for (; *s; s++)
> +    {
> +      if (*s == '"')
> +        store (d, i, bscount + 1, '\\');

This sholud be i = store (d, i , ...), so we don't lose the backslashes.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.