emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62982: closed (Command-line parsing fails if parameters contain spac


From: GNU bug Tracking System
Subject: bug#62982: closed (Command-line parsing fails if parameters contain spaces)
Date: Fri, 21 Apr 2023 02:52:01 +0000

Your message dated Thu, 20 Apr 2023 21:51:21 -0500
with message-id <6441FA29.9080907@gmail.com>
and subject line now fixed in Git master
has caused the debbugs.gnu.org bug report #62982,
regarding Command-line parsing fails if parameters contain spaces
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
62982: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62982
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Command-line parsing fails if parameters contain spaces Date: Thu, 20 Apr 2023 22:03:19 -0400
Forwarding problem report to assign a bug number to this.

In brief, the code that restores certain variables assigned as a result
of the command line arguments fails if any of those values contain
whitespace.  This is a problem becuase the --target_board option can
legitimately be a list of mulitple targets to run.

-- Jacob

--- Begin Message --- Subject: [PATCH] runtest: Allow multi-word arguments Date: Mon, 17 Apr 2023 20:35:52 +0200
From: Christoph Müllner <christoph.muellner@vrull.eu>

A recent change (5fafcd43) introduced a command line argument cache,
that ensures that command line arguments have a higher priority
than configuration files.

That cache uses the following code to save and restore:
    save_cmd_var:
      upvar 1 $name target_var
    restore_cmd_vars"
      uplevel 1 set $name $value

This works well unless $value becomes a multi-word string
(i.e. a string that contains spaces), because in this case
the command becomes:
    uplevel 1 set $name arg-word0 arg-word1 ...
Obviously this will trigger the following error:
    wrong # args: should be "set varName ?newValue?"
Quoting "$value" does not help, because the quotes are evaluated before
executing set.

Let's fix this by using upvar for the restore code as well:
    upvar 1 $name target_var
    set $target_var "$value"
Here, the quotes will be evaluated when executing the set command.

This has been reported in a downstream project, where this bug prevented
running the GCC regression tests when building in multilib
configuration:
    https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1201
The actual command in this report was:
    set target_list riscv-sim/-march=rv32imac/-mabi=ilp32/-mcmodel=medlow \
      riscv-sim/-march=rv32imafdc/-mabi=ilp32d/-mcmodel=medlow \
      riscv-sim/-march=rv64imac/-mabi=lp64/-mcmodel=medlow \
      riscv-sim/-march=rv64imafdc/-mabi=lp64d/-mcmod

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
---
 runtest.exp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/runtest.exp b/runtest.exp
index 7c6018f..0829fda 100644
--- a/runtest.exp
+++ b/runtest.exp
@@ -432,7 +432,8 @@ namespace eval ::dejagnu::command_line {
        variable cmd_var_list
 
        foreach {name value} $cmd_var_list {
-           uplevel 1 set $name $value
+           upvar 1 $name target_var
+           set $target_var "$value"
        }
        verbose "Variables set by command line arguments restored." 4
     }
-- 
2.39.2



--- End Message ---

--- End Message ---
--- Begin Message --- Subject: now fixed in Git master Date: Thu, 20 Apr 2023 21:51:21 -0500 User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0
Fixed in commit c298959ef991b389b64a825f70094738c6a48780.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]