Re: bin/60921: m4 --undefine argument does not undefine

[Phil Hagelberg <phil%hagelb.org@localhost>]

"Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost> writes:

>  For now, it doesn't make sense to request a GNU extension and then
>  to undefine (or redefine) it. But with future multiple GNU extensions
>  you may want to ask for them but also remove specific ones.

I don't know what this means; I'm not really concerned with GNU. I am
just basing this off the seemingly intended behavior described in the
NetBSD man page for m4.

Maybe I should back up. My real purpose for reporting this bug is that I
wish to use m4 to process existing documents that have the word "shift"
in them. Right now NetBSD's m4 treats that word as a macro even when it
is clearly not being used as such. When I read the manual, I saw that it
said I should be able to undefine it so that these documents could be
processed normally, but that is not the case.

Looking at it more closely, there may be more to the bug. The manual
shows that `shift' is a built-in macro which is called using parens; the
example shows:

  shift(arg1, ...)

Most other macros which are documented as using parens will not be invoked
when they are merely referred to by name. For example:

  echo len | m4 # prints "len"

For some reason, the shift macro does not work that way; any unquoted
use of the word "shift" will invoke the macro:

  echo shift this over | m4 # prints " this over"

So if the --undefine feature worked, that could be used as a workaround
to this problem. But it would be even better if that weren't necessary
and the shift macro behaved like the other macros and was not invoked
unless called using parens.

The word "shift" is not particularly unlikely to be found in documents
processed by m4; this behavior makes it very easy to invoke by accident.

Would it be better to open a separate issue for this?