bugmake - Bugs: bug #65759, handling of "-" and...

 
 

bug #65759: handling of "-" and "--" on command line

Submitter:  None
Submitted:  Sun 19 May 2024 02:35:54 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.4.1 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 23 May 2024 12:27:05 AM UTC, comment #5: 

I looked through the code.  This is explicitly handled, and ignored, with a commit message by Roland from 1995 saying only:

commit 636435e5c25d39fc5d52edf936e8e7a410b31b1a
Author: Roland McGrath <roland@redhat.com>
Date:   1995-03-07 22:31:01 +0000

    (decode_switches): If non-option arg is "-", ignore it.

So, I'm not sure why this was done or what the right thing to do is going forward.  Maybe we should be printing a warning.  I wonder if it's there because some makefiles contain recipes like this:

  submake:
          $(MAKE) -$(MAKEFLAGS)

where, if MAKEFLAGS is empty you get make -.

I will think about it.

Paul D. Smith <psmith>
Group administrator
Mon 20 May 2024 02:46:46 PM UTC, comment #4: 

(original poster) Understood about --. WRT -, I don't think it should be an error, I think it should be treated as a filename as Dmitry says.

IMHO the interesting question is: given that - should be treated as a valid filename, should it be required to come after a --? I haven't read the POSIX standard closely so I don't know what it might require but intuitively it seems that - without -- could be treated as a bogus option whereas after -- it must be a valid filename. This does not seem to be happening now:

$ cat Makefile
%:; @:$(info creating $@)

$ make -- foo
creating foo

$ make -- -
make: * No targets.  Stop.

Anonymous
Mon 20 May 2024 01:18:30 PM UTC, comment #3: 

Yes it is a valid filename but the problem, as pointed out in the original description, is that make doesn't treat it that way.  At least not all the time.  It appears that the code wants to treat it as if you'd used "-f-" but it doesn't appear to work correctly.  I do agree that this behavior is duplicative and unpleasant.

For example:

$ make x
make: *** No rule to make target 'x'.  Stop.

but:

$ make -
make: *** No targets specified and no makefile found.  Stop.


Paul D. Smith <psmith>
Group administrator
Mon 20 May 2024 02:04:15 AM UTC, comment #2: 

- is a valid filename.
i think, everybody would be better off, with one and only one syntax of having make read from stdin.

Dmitry Goncharov <dgoncharov>
Sun 19 May 2024 10:02:45 PM UTC, comment #1: 

The behavior of "make --" is as expected because according to the POSIX standard, the argument -- specifies that no files after it are to be considered options even if they begin with "-".

So for example if you wanted to make a target named -f you can't use make -f because "-f" is a valid option name.  You'd have to use make -- -f.

However, I do agree that make - (one dash) should be considered an error.  Many programs use a single dash to mean "read from stdin" but make doesn't do this.

Paul D. Smith <psmith>
Group administrator
Sun 19 May 2024 02:35:54 PM UTC, original submission:  

I don't know whether this is considered a bug per se but it's pretty confusing. Consider the following makefile:

$ cat Makefile
all:; @:$(info making $@)

$ make
making all

$ make -
making all

$ make --
making all

It seems to treat "-" and "--" as options with no effect similar to -b or -m. However these are also considered legal target names:

$ cat Makefile
-:; @:$(info creating $@)

$ make -
creating -

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code