buggxmessage - Bugs: bug #51648, Stop processing command-line...

 
 

bug #51648: Stop processing command-line arguments with --

Submitter:  R. Diez <rdiez>
Submitted:  Thu 03 Aug 2017 07:24:41 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  timothym
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Oct 2017 01:04:36 AM UTC, comment #10: 

Hi, thanks for the reply - it's good to know there's a usable workaround for people in your situation. I've added a note to the manual, so that'll be in the next release.

If command line arguments in gxmessage seem unusual or buggy, take a look at what xmessage does with the same arguments.

The two programs should behave the same way, with gxmessage intentionally behaving as much as possible like xmessage (...even including weirdness, like the stuff you've noticed).

Gxmessage's main goal is to behave as much like xmessage as possible, which limits scope for deviation a bit :/

Timothy Musson <timothym>
Group administrator
Thu 05 Oct 2017 09:54:44 AM UTC, comment #9: 

It does work with "-center". I hope that the command-line argument parser always compares the option strings without trimming blanks.

In any case, mentioning that work-around in the manual page is the right thing to do.

I am worried that command-line parsing is not consistent. For example, if you forget the argument for -center , you get an error message:

$ gxmessage -center
gxmessage: message text is required
Try `gxmessage --help' for more information

But this shows a dialog with the text "-file" inside:

$ gxmessage -file

The following does complain as expected though:

$ gxmessage -file a
gxmessage: unable to read file

I'm afraid that I do not have the time to test all gxmessage options at the moment.

R. Diez <rdiez>
Thu 05 Oct 2017 08:45:52 AM UTC, comment #8: 

Hi :)

Just wondering whether you've had a chance to try the workaround of padding the message text with a space character - e.g.:

  $ MSG=-center; gxmessage "$MSG "

I know it's not pretty, but it's super simple. If it solves your problem, I'll make a note of it in gxmessage's manual page.

Thanks,

Tim



Timothy Musson <timothym>
Group administrator
Wed 20 Sep 2017 01:43:01 PM UTC, comment #7: 

My own example does what it should, and works correctly at my end. Tested before posting, and again now.

However, I hadn't clearly understood the exact problem you're having. Sorry about that. So let's nail it down. You'd like to be able to do this...

  $ MSG=whatever; gxmessage "$MSG"

...where MSG could be absolutely anything, possibly even something that looks exactly like a gxmessage option, e.g. -center

And the obvious way to do that would be with '--', i.e.:

  $ MSG=whatever; gxmessage -- "$MSG"

Okay, got it.

Gimme a couple of days to think about it, and I'll get back to you.

In the meantime, a work-around might be to prefix or suffix your message text with a space character (' ') before feeding it to gxmessage, something like this:

  $ MSG=-center; gxmessage "$MSG "

This workaround appears to work with xmessage as well. Does this help at all with your project?

Timothy Musson <timothym>
Group administrator
Tue 19 Sep 2017 08:58:30 AM UTC, comment #6: 

Did you actually try your own example? This is what I get:

  $ gxmessage  "-center"
  gxmessage: message text is required
  Try `gxmessage --help' for more information

In fact, no amount of quoting helps. That is why the GNU tools introduced the "--" switch.

Lacking '--' in some tools can actually be pretty serious, up to becoming a security risk. Every time you add a command-line option, you have to ask yourself how bad the damage can be. From experience, you will be eventually hit.

At the very least, you should document this shortcoming in gxmessage's help or man page. We all want reliable software, and not just something that works most of the time.

R. Diez <rdiez>
Tue 19 Sep 2017 07:21:50 AM UTC, comment #5: 

Quoting the strings fed to g/xmessage should prevent leading '-' characters from being mistaken for command line options.

So something like this in a bash script ought to work with gxmessage (falling back to xmessage if gxmessage isn't installed), and cope with leading '-' characters in the title and message text:

  XMESSAGE=$(which gxmessage) || xmessage
  TITLE=Test
  MSG='-center is part of this message'
  # MSG=$(< "$FILENAME")
  # MSG=$(sort "$FILENAME" | uniq)
  # MSG=$(construct_message "$FILENAME")
  $XMESSAGE -title "${TITLE}" "${MSG:-No message}"

Is any of that useful?

Timothy Musson <timothym>
Group administrator
Tue 19 Sep 2017 06:19:17 AM UTC, comment #4: 

I have written some scripts which do some processing and display a dialog box when finished. That means that my scripts call gxmessage at the end. Some scripts let the user specify the dialog box title or message, and some others build the dialog box message by taking some text from the output of the tasks performed.

The user could start the message text with a hyphen ('-'), or the text gathered from the processing output could also easily start with a hyphen, which would break the gxmessage command.

Trying to fix it is not trivial, as Bash is not very good at string handling. Documenting such limitations does not work in real life.

I already created a bug for xmessage, it's here:

https://bugs.freedesktop.org/show_bug.cgi?id=102815

R. Diez <rdiez>
Tue 19 Sep 2017 03:06:26 AM UTC, comment #3: 

Hey :)

It's true (and a good/fair point) that gxmessage already has a few more command-line options than xmessage. (All but 2 of the additional options are to help it play well with various Window Managers, rather than adding functionality beyond what xmessage can do). Often it's hard to know where to draw the line between drop-in compatibility, and worthwhile differences.

An '-endofoptions' flag could be implemented, but using a command-line option to get '--' to behave as expected is itself atypical, so seems to defeat the purpose a bit.

Is there something specific you're wanting to do with gxmessage, that's hard or impossible to do with gxmessage's current behaviour? You might be able to convince me with a good example that illustrates why it's a worthwhile change :)

Another option might be to file a similar bug report against xmessage (it's part of X Window System / Xorg). I think it's unlikely they'd change anything but, if they do, gxmessage will follow along.

Tim

Timothy Musson <timothym>
Group administrator
Sun 17 Sep 2017 07:28:35 AM UTC, comment #2: 

gxmessage already has more command-line options than xmessage. How about adding an '-endofoptions' one (or similar) that behaves like '--' in other tools?

R. Diez <rdiez>
Sat 16 Sep 2017 09:27:13 AM UTC, comment #1: 

Hi! Thanks very much for the report - I apologise for my late reply. I'm closing this bug report because, although you're right that gxmessage's treatment of '--' isn't the commonly expected behaviour, it does mirror the behaviour of xmessage.

If gxmessage behaved unlike xmessage, it'd potentially break scripts where gxmessage is being used as a drop-in alternative to xmessage.

Anyway, I really appreciate your bug report - thanks very much, and again, sorry for the late reply :)

Tim

Timothy Musson <timothym>
Group administrator
Thu 03 Aug 2017 07:24:41 AM UTC, original submission:  

gxmessage should stop processing command-line arguments when it encounters a '--'. All arguments after -- should be considered part of the message.

This '--' behaviour is a standard feature in many tools. Otherwise, if the messsage starts with a '-', you may hit a command-line option inadvertently.

R. Diez <rdiez>

 

(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 timothym (Posted a comment)
  • -email is unavailable- added by rdiez (Submitted the item)
  •  

    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.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-09-16 timothym StatusNone Wont Fix
        Assigned toNone timothym
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code