> generally the [0] argument can also be -- How? Can you please give an example?
The upstream GNOME Terminal change that we're affected by is https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8074. GNOME Terminal used to silently ignore non-option parameters (before the "--" if such a parameter was present), now rejects them as error. The wrapper script erroneously passes such an extra argument which now causes the problem. It's unclear to me: How would the fix involve possibly _adding_ yet another parameter, rather than _removing_ the superfluous one? I have to admit that I don't necessarily understand _all_ possible code paths in that script, nor do I understand what the script really wants to do, but I aimed to change it in a no-op way, i.e. its behavior should be identical to what it used to do with older GNOME Terminal versions; also I tested it with a simple `gnome-terminal --class foo` or similar command and it worked as expected. But again, I might have missed something, might mishandle a more complex command line. But I can't see how _inserting_ yet another parameter could be a fix, adapting to newer GNOME Terminal, yet maintaining the previous behavior of the wrapper script. We'd really need the author of that wrapper script to take a look. (I don't know who that person is.) ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #8074 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8074 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2073881 Title: gnome-terminal stopped accepting arguments: # Failed to parse arguments: Too many arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2073881/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
