Bug 2873 - insufficient warnings on illegal macro names in macro file
Summary: insufficient warnings on illegal macro names in macro file
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
: 2629 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-17 13:17 UTC by benedict
Modified: 2015-01-07 23:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-05-24 19:58:37 UTC
Embargoed:


Attachments (Terms of Use)

Description benedict 1999-05-17 13:17:12 UTC
Put the following illegal definitions in your macro file -
warnings will only be issued on some of them

%solaris2.x foobar
%solaris.x foobar
%solari.x foobar
%solar.x foobar
%sola.x foobar
%sol.x foobar
%so.x foobar
%s.x foobar

%irix6.x irix6.5
%hpux10.x  hpux10.20

%mu.x foobar
%mu.macro foobar

The warnings are

Macro %so has illegal name (%define)
Macro %s has illegal name (%define)
Macro %mu has illegal name (%define)
Macro %mu has illegal name (%define)

Comment 1 Jeff Johnson 1999-05-17 14:05:59 UTC
At the core of your request is how macro names should be parsed
in context. The rpm-2.5.x behavior was to parse non-space(s) until
next space, and according to that algorithm, you are expecting
error messages saying "%foo.bar" is an illegal name. (Note: there
is also the variant %{foo.bar} which is demarked by curly braces.)

In rpm 3.0, the parser accepts permitted characters in a name. That
will eventually permit constructs like
	%define	%sol	solaris2
	%sol2.5	=> solaris2.5
without the curly brace artifacts (e.g. %{sol2}.5.

Another implementation feature in rpm-3.0 is the ability to overload
pre-existing non-macro tokens (e.g. %prep) in a transparent manner
	%prep	%%prep
Note that each of the % in the above statement is different. First
there's the macro %, then the (obvious) escaping %, and finally the
1st character of the (non-macro!) token %prep. So, given the ability
to overload non-macro tokens with macros that might not be defined
when parsed, there is no way to generate an error message about
illegal macro names when the macro name is parsed.

Comment 2 Jeff Johnson 1999-05-24 19:56:59 UTC
*** Bug 2629 has been marked as a duplicate of this bug. ***

The following spec file snippet should echo twice when built
with buildos irix6.5 - in 3.0 it echos only once.

%prep

%define mymacro irix6.5

%ifos %{mymacro}
echo "Expansion of ifos %{mymacro} is OK"
%endif

%ifos iris6.5
echo "Expansion of ifos %{mymacro} is OK"
%endif

The output is

Executing: %prep
+ umask 022
+ cd /tmp/benedict/BUILD-test-3.0
+ echo Expansion of ifos irix6.5 is OK
Expansion of ifos irix6.5 is OK
+ exit 0


------- Additional Comments From jbj  05/14/99 14:35 -------
Macros are correctly expanded before processing %ifX statements.

Your example has a typo (iris6.5 vs. irix6.5), I can't tell which is
wrong without examining uname(2) strings on an SGI platform.

Please reopen this bug if there is still a problem.

------- Additional Comments From benedict.dk  05/17/99 05:53 -------
OK. Sorry about the typo.

------- Additional Comments From benedict.dk  05/17/99 09:30 -------
See Bug # 2873
    The original problem for me was that I did not get any warning
when I defined %irix6.x in a macro file - so I thought it was not
expanded when I used a conditional such as
    %ifos %{irix6.x}

Comment 3 Jeff Johnson 1999-05-24 19:58:59 UTC
Here's my typo:
        %define %sol2    solaris2
        %sol2.5 => solaris2.5


Note You need to log in before you can comment on or make changes to this bug.