[2/2] Make gdbserver work with filename-only binaries
Commit Message
Simon mentioned on IRC that, after the startup-with-shell feature has
been implemented on gdbserver, it is not possible to specify a
filename-only binary, like:
$ gdbserver :1234 a.out
/bin/bash: line 0: exec: a.out: not found
During startup program exited with code 127.
Exiting
This happens on systems where the current directory "." is not listed
in the PATH environment variable. Although include "." in the PATH
variable is a possible workaround, this can be considered a regression
because before startup-with-shell it was possible to use only the
filename (due to reason that gdbserver used "exec*" directly).
The idea of the patch is to perform a call to "gdb_abspath" and adjust
the PROGRAM_NAME variable before the call to "create_inferior". This
adjustment will consist of tilde-expansion or prefixing PROGRAM_NAME
using the CURRENT_DIRECTORY (a variable that was specific to GDB, but
has been put into common/common-defs.h and now is set/used by
gdbserver as well), thus transforming PROGRAM_NAME in an absolute
path.
This mimicks the behaviour seen on GDB (look at "openp" and
"attach_inferior", for example). Now, we'll always execute the binary
using its full path on gdbserver.
I am also submitting a testcase which exercises the scenario described
above. Because the test requires copying (and deleting) files
locally, I decided to restrict its execution to non-remote
targets/hosts. I've also had to do a minor adjustment on
gdb.server/non-existing-program.exp's regexp in order to match the
correct error message.
Built and regtested on BuildBot, without regressions.
gdb/ChangeLog:
2018-02-09 Sergio Durigan Junior <sergiodj@redhat.com>
* common/common-def.h (current_directory): Move here...
* defs.h (current_directory): ...from here.
gdb/gdbserver/ChangeLog:
2018-02-09 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c: Include "filenames.h" and "pathstuff.h".
(current_directory): New global variable.
(adjust_program_name_path): New function.
(attach_inferior): Call "adjust_program_name_path" before
"create_inferior".
(captured_main): Likewise.
(process_serial_event): Likewise.
gdb/testsuite/ChangeLog:
2018-02-09 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.server/abspath.exp: New file.
* gdb.server/non-existing-program.exp: Adjust regex for the
"startup-with-shell enabled" case.
---
gdb/common/common-defs.h | 3 ++
gdb/defs.h | 4 --
gdb/gdbserver/server.c | 36 +++++++++++++++
gdb/testsuite/gdb.server/abspath.exp | 54 +++++++++++++++++++++++
gdb/testsuite/gdb.server/non-existing-program.exp | 2 +-
5 files changed, 94 insertions(+), 5 deletions(-)
create mode 100644 gdb/testsuite/gdb.server/abspath.exp
Comments
On 2018-02-09 08:42 PM, Sergio Durigan Junior wrote:
> Simon mentioned on IRC that, after the startup-with-shell feature has
> been implemented on gdbserver, it is not possible to specify a
> filename-only binary, like:
>
> $ gdbserver :1234 a.out
> /bin/bash: line 0: exec: a.out: not found
> During startup program exited with code 127.
> Exiting
>
> This happens on systems where the current directory "." is not listed
> in the PATH environment variable. Although include "." in the PATH
> variable is a possible workaround, this can be considered a regression
> because before startup-with-shell it was possible to use only the
> filename (due to reason that gdbserver used "exec*" directly).
>
> The idea of the patch is to perform a call to "gdb_abspath" and adjust
> the PROGRAM_NAME variable before the call to "create_inferior". This
> adjustment will consist of tilde-expansion or prefixing PROGRAM_NAME
> using the CURRENT_DIRECTORY (a variable that was specific to GDB, but
> has been put into common/common-defs.h and now is set/used by
> gdbserver as well), thus transforming PROGRAM_NAME in an absolute
> path.
>
> This mimicks the behaviour seen on GDB (look at "openp" and
> "attach_inferior", for example). Now, we'll always execute the binary
> using its full path on gdbserver.
>
> I am also submitting a testcase which exercises the scenario described
> above. Because the test requires copying (and deleting) files
> locally, I decided to restrict its execution to non-remote
> targets/hosts. I've also had to do a minor adjustment on
> gdb.server/non-existing-program.exp's regexp in order to match the
> correct error message.
Hi Sergio,
The behavior is still different than for GDB (and previous gdbservers), in
the case where you specify a filename-only binary that is found in PATH. For
example, try "gdb ls" and/or "gdbserver ls". The expected behavior is to
search for a file with this name in the current directory, and if there isn't
one, to search in the PATH. This is what openp does when OPF_TRY_CWD_FIRST
is passed.
Bringing openp to gdbserver may not be easy nor desirable, since it supports
some concepts that don't exist in gdbserver (like $-variables). Also, we would
not really want to open the file in this case, only see if it exists.
I didn't think this through completely, but maybe we could do something simpler,
if the program_name doesn't contain a directory separator and the file exists in
the current working directory, we add "./" in front of it when passing it to the
shell? I think all three use cases would work:
- gdbserver :1234 foo (foo in current directory)
- gdbserver :1234 foo (foo in PATH)
- gdbserver :1234 ./foo
Simon
On Sunday, February 11 2018, Simon Marchi wrote:
> On 2018-02-09 08:42 PM, Sergio Durigan Junior wrote:
>> Simon mentioned on IRC that, after the startup-with-shell feature has
>> been implemented on gdbserver, it is not possible to specify a
>> filename-only binary, like:
>>
>> $ gdbserver :1234 a.out
>> /bin/bash: line 0: exec: a.out: not found
>> During startup program exited with code 127.
>> Exiting
>>
>> This happens on systems where the current directory "." is not listed
>> in the PATH environment variable. Although include "." in the PATH
>> variable is a possible workaround, this can be considered a regression
>> because before startup-with-shell it was possible to use only the
>> filename (due to reason that gdbserver used "exec*" directly).
>>
>> The idea of the patch is to perform a call to "gdb_abspath" and adjust
>> the PROGRAM_NAME variable before the call to "create_inferior". This
>> adjustment will consist of tilde-expansion or prefixing PROGRAM_NAME
>> using the CURRENT_DIRECTORY (a variable that was specific to GDB, but
>> has been put into common/common-defs.h and now is set/used by
>> gdbserver as well), thus transforming PROGRAM_NAME in an absolute
>> path.
>>
>> This mimicks the behaviour seen on GDB (look at "openp" and
>> "attach_inferior", for example). Now, we'll always execute the binary
>> using its full path on gdbserver.
>>
>> I am also submitting a testcase which exercises the scenario described
>> above. Because the test requires copying (and deleting) files
>> locally, I decided to restrict its execution to non-remote
>> targets/hosts. I've also had to do a minor adjustment on
>> gdb.server/non-existing-program.exp's regexp in order to match the
>> correct error message.
>
> Hi Sergio,
Hey, Simon,
> The behavior is still different than for GDB (and previous gdbservers), in
> the case where you specify a filename-only binary that is found in PATH. For
> example, try "gdb ls" and/or "gdbserver ls". The expected behavior is to
> search for a file with this name in the current directory, and if there isn't
> one, to search in the PATH. This is what openp does when OPF_TRY_CWD_FIRST
> is passed.
Ah, I guess I didn't consider this (obvious) scenario for gdbserver. I
was thinking that gdbserver (before the startup-with-shell feature)
would not work with binaries in PATH...
> Bringing openp to gdbserver may not be easy nor desirable, since it supports
> some concepts that don't exist in gdbserver (like $-variables). Also, we would
> not really want to open the file in this case, only see if it exists.
Yeah, it crossed my mind to move openp to common, but it's not a trivial
task as you pointed.
> I didn't think this through completely, but maybe we could do something simpler,
> if the program_name doesn't contain a directory separator and the file exists in
> the current working directory, we add "./" in front of it when passing it to the
> shell? I think all three use cases would work:
>
> - gdbserver :1234 foo (foo in current directory)
> - gdbserver :1234 foo (foo in PATH)
> - gdbserver :1234 ./foo
So, what do you think of checking if the file exists in the CWD (and is
executable), and prefixing it with current_directory, as I'm doing with
this patch? I personally prefer to be more verbose, so using the full
path is better IMHO than just adding "./".
Thanks,
Second version.
These two patches fix the issue pointed by Simon on IRC, that
gdbserver doesn't recognize filename-only binaries anymore:
$ gdbserver :1234 a.out
/bin/bash: line 0: exec: a.out: not found
During startup program exited with code 127.
Exiting
The first one is a preparation patch (and can go in independently),
which moves path-manipulation functions from utils.c to a new
common/pathstuff.c, making them available for gdbserver as well.
The second patch is the fix itself.
More details in each message.
> Ah, I guess I didn't consider this (obvious) scenario for gdbserver. I
> was thinking that gdbserver (before the startup-with-shell feature)
> would not work with binaries in PATH...
It would, but it would be at the discretion of each target
implementation. linux-low was doing it by calling execv first,
which doesn't search the PATH, and then calling execvp if
the first execv call failed with a "not found" error.
> > I didn't think this through completely, but maybe we could do
> > something simpler, if the program_name doesn't contain a directory
> > separator and the file exists in the current working directory, we
> > add "./" in front of it when passing it to the shell? I think all
> > three use cases would work:
> >
> > - gdbserver :1234 foo (foo in current directory)
> > - gdbserver :1234 foo (foo in PATH)
> > - gdbserver :1234 ./foo
>
> So, what do you think of checking if the file exists in the CWD (and is
> executable), and prefixing it with current_directory, as I'm doing with
> this patch? I personally prefer to be more verbose, so using the full
> path is better IMHO than just adding "./".
I agree with Simon that we shouldn't (and don't really need to) touch
the file when it contains some directory information in it. As far as
I can tell, it already works as is, both with and without shell startup.
$ gdbserver --once :4444 simple/simple_main
Process simple/simple_main created; pid = 15400
Listening on port 4444
$ gdbserver --no-startup-with-shell --once :4444 simple/simple_main
Process simple/simple_main created; pid = 15432
Listening on port 4444
So, I think the only case that we need to worry about is the case
where exec_file is a basename. For that, I think the following test
should be sufficient:
if (lbasename (exec_file) == exec_file)
... If it returns anything else than exec file, it's either a full
path, or a relative path with some directory information in it.
I agree with you, Sergio, that I think that expanding to the absolute
path would be cleaner. I'm not sure whether adding "." + SLASH_STRING
is going to work everywhere... I'd rather not ask myself the question,
and just expand to a full path, since you've done the work to do it
anyways.
Third version.
These two patches fix the issue pointed by Simon on IRC, that
gdbserver doesn't recognize filename-only binaries anymore:
$ gdbserver :1234 a.out
/bin/bash: line 0: exec: a.out: not found
During startup program exited with code 127.
Exiting
The first one is a preparation patch (and can go in independently),
which moves path-manipulation functions from utils.c to a new
common/pathstuff.c, making them available for gdbserver as well.
The second patch is the fix itself.
More details in each message.
On Tuesday, February 27 2018, I wrote:
> Third version.
>
> These two patches fix the issue pointed by Simon on IRC, that
> gdbserver doesn't recognize filename-only binaries anymore:
>
> $ gdbserver :1234 a.out
> /bin/bash: line 0: exec: a.out: not found
> During startup program exited with code 127.
> Exiting
>
> The first one is a preparation patch (and can go in independently),
> which moves path-manipulation functions from utils.c to a new
> common/pathstuff.c, making them available for gdbserver as well.
>
> The second patch is the fix itself.
>
> More details in each message.
Simon reminded me that this patch is also a good fit for the 8.1 branch,
so I went ahead and pushed it there.
506817a3abd98859eb3474389e756c0253cc28a1
2441702a72f324e41a1624dc042b334f375e2d81
6d607b8812b35ff36fbbad2915696f6669f86a32
Thanks,
> Simon reminded me that this patch is also a good fit for the 8.1 branch,
> so I went ahead and pushed it there.
>
> 506817a3abd98859eb3474389e756c0253cc28a1
> 2441702a72f324e41a1624dc042b334f375e2d81
> 6d607b8812b35ff36fbbad2915696f6669f86a32
Thanks for getting this through, Sergio and Simon.
Just a quick reminder that, now that the .0 is out, all new patches
pushed on the branch should have a corresponding PR number, with
the target milestone set to 8.1. This is to be able to give users
an actionable list of PRs they can look at if they are wondering
what the difference between 8.0 and 8.1 is. Is there one for this
issue? If not, it's good enough to create one after the fact, as
long as the PR points to the various discussions and maybe gives
the SHA1 of the various commits, I think we're good.
Thank you!
On 1 March 2018 at 03:55, Joel Brobecker <brobecker@adacore.com> wrote:
>> Simon reminded me that this patch is also a good fit for the 8.1 branch,
>> so I went ahead and pushed it there.
>>
>> 506817a3abd98859eb3474389e756c0253cc28a1
>> 2441702a72f324e41a1624dc042b334f375e2d81
>> 6d607b8812b35ff36fbbad2915696f6669f86a32
>
Hi,
These new patches seem to cause problems with building for ming (using
i686-w64-mingw32-g++):
/gdb/common/pathstuff.c: In function 'gdb::unique_xmalloc_ptr<char>
gdb_realpath(const char*)':
/gdb/common/pathstuff.c:56:14: error: 'MAX_PATH' was not declared in this scope
char buf[MAX_PATH];
^
/gdb/common/pathstuff.c:57:5: error: 'DWORD' was not declared in this scope
DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
^
/gdb/common/pathstuff.c:57:11: error: expected ';' before 'len'
DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
^
/gdb/common/pathstuff.c:63:9: error: 'len' was not declared in this scope
if (len > 0 && len < MAX_PATH)
^
/gdb/common/pathstuff.c:64:54: error: 'buf' was not declared in this scope
return gdb::unique_xmalloc_ptr<char> (xstrdup (buf));
^
make[2]: *** [pathstuff.o] Error 1
I saw this while rebuilding branch 8.1, I didn't check master.
Sorry if this has already been reported, I can't find any mention of
this problem in the list archives.
I suspect there's already a recommended way of handling MAX_PATH cross-platform.
Thanks
Christophe
> Thanks for getting this through, Sergio and Simon.
>
> Just a quick reminder that, now that the .0 is out, all new patches
> pushed on the branch should have a corresponding PR number, with
> the target milestone set to 8.1. This is to be able to give users
> an actionable list of PRs they can look at if they are wondering
> what the difference between 8.0 and 8.1 is. Is there one for this
> issue? If not, it's good enough to create one after the fact, as
> long as the PR points to the various discussions and maybe gives
> the SHA1 of the various commits, I think we're good.
>
> Thank you!
> --
> Joel
On 2018-03-01 08:08, Christophe Lyon wrote:
> These new patches seem to cause problems with building for ming (using
> i686-w64-mingw32-g++):
>
> /gdb/common/pathstuff.c: In function 'gdb::unique_xmalloc_ptr<char>
> gdb_realpath(const char*)':
> /gdb/common/pathstuff.c:56:14: error: 'MAX_PATH' was not declared in
> this scope
> char buf[MAX_PATH];
> ^
> /gdb/common/pathstuff.c:57:5: error: 'DWORD' was not declared in this
> scope
> DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
> ^
> /gdb/common/pathstuff.c:57:11: error: expected ';' before 'len'
> DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
> ^
> /gdb/common/pathstuff.c:63:9: error: 'len' was not declared in this
> scope
> if (len > 0 && len < MAX_PATH)
> ^
> /gdb/common/pathstuff.c:64:54: error: 'buf' was not declared in this
> scope
> return gdb::unique_xmalloc_ptr<char> (xstrdup (buf));
> ^
> make[2]: *** [pathstuff.o] Error 1
>
> I saw this while rebuilding branch 8.1, I didn't check master.
>
> Sorry if this has already been reported, I can't find any mention of
> this problem in the list archives.
>
> I suspect there's already a recommended way of handling MAX_PATH
> cross-platform.
>
> Thanks
>
> Christophe
MAX_PATH is windows specific, note that this code is in an #if defined
(_WIN32) guard. I think we just need to add #include <windows.h> with
the same guard.
Simon
On Wednesday, February 28 2018, Joel Brobecker wrote:
>> Simon reminded me that this patch is also a good fit for the 8.1 branch,
>> so I went ahead and pushed it there.
>>
>> 506817a3abd98859eb3474389e756c0253cc28a1
>> 2441702a72f324e41a1624dc042b334f375e2d81
>> 6d607b8812b35ff36fbbad2915696f6669f86a32
>
> Thanks for getting this through, Sergio and Simon.
>
> Just a quick reminder that, now that the .0 is out, all new patches
> pushed on the branch should have a corresponding PR number, with
> the target milestone set to 8.1. This is to be able to give users
> an actionable list of PRs they can look at if they are wondering
> what the difference between 8.0 and 8.1 is. Is there one for this
> issue? If not, it's good enough to create one after the fact, as
> long as the PR points to the various discussions and maybe gives
> the SHA1 of the various commits, I think we're good.
Hi Joel,
Sorry about this, I forgot about the need to create a PR when the
release is out. There is no PR for this bug, so I created one following
the specifications:
https://sourceware.org/bugzilla/show_bug.cgi?id=22907
Please let me know if there's something else I can do.
Thanks,
On Thursday, March 01 2018, Christophe Lyon wrote:
> On 1 March 2018 at 03:55, Joel Brobecker <brobecker@adacore.com> wrote:
>>> Simon reminded me that this patch is also a good fit for the 8.1 branch,
>>> so I went ahead and pushed it there.
>>>
>>> 506817a3abd98859eb3474389e756c0253cc28a1
>>> 2441702a72f324e41a1624dc042b334f375e2d81
>>> 6d607b8812b35ff36fbbad2915696f6669f86a32
>>
>
> Hi,
>
> These new patches seem to cause problems with building for ming (using
> i686-w64-mingw32-g++):
I'm taking a look at this right now. Thanks for reporting.
> /gdb/common/pathstuff.c: In function 'gdb::unique_xmalloc_ptr<char>
> gdb_realpath(const char*)':
> /gdb/common/pathstuff.c:56:14: error: 'MAX_PATH' was not declared in this scope
> char buf[MAX_PATH];
> ^
> /gdb/common/pathstuff.c:57:5: error: 'DWORD' was not declared in this scope
> DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
> ^
> /gdb/common/pathstuff.c:57:11: error: expected ';' before 'len'
> DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
> ^
> /gdb/common/pathstuff.c:63:9: error: 'len' was not declared in this scope
> if (len > 0 && len < MAX_PATH)
> ^
> /gdb/common/pathstuff.c:64:54: error: 'buf' was not declared in this scope
> return gdb::unique_xmalloc_ptr<char> (xstrdup (buf));
> ^
> make[2]: *** [pathstuff.o] Error 1
>
> I saw this while rebuilding branch 8.1, I didn't check master.
>
> Sorry if this has already been reported, I can't find any mention of
> this problem in the list archives.
>
> I suspect there's already a recommended way of handling MAX_PATH cross-platform.
>
> Thanks
>
> Christophe
>
>> Thanks for getting this through, Sergio and Simon.
>>
>> Just a quick reminder that, now that the .0 is out, all new patches
>> pushed on the branch should have a corresponding PR number, with
>> the target milestone set to 8.1. This is to be able to give users
>> an actionable list of PRs they can look at if they are wondering
>> what the difference between 8.0 and 8.1 is. Is there one for this
>> issue? If not, it's good enough to create one after the fact, as
>> long as the PR points to the various discussions and maybe gives
>> the SHA1 of the various commits, I think we're good.
>>
>> Thank you!
>> --
>> Joel
> Sorry about this, I forgot about the need to create a PR when the
> release is out. There is no PR for this bug, so I created one following
> the specifications:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=22907
>
> Please let me know if there's something else I can do.
No worries. This is perfect, thank you!
@@ -91,4 +91,7 @@
/* Pull in gdb::unique_xmalloc_ptr. */
#include "common/gdb_unique_ptr.h"
+/* String containing the current directory (what getwd would return). */
+extern char *current_directory;
+
#endif /* COMMON_DEFS_H */
@@ -423,10 +423,6 @@ enum info_proc_what
IP_ALL
};
-/* * String containing the current directory (what getwd would return). */
-
-extern char *current_directory;
-
/* * Default radixes for input and output. Only some values supported. */
extern unsigned input_radix;
extern unsigned output_radix;
@@ -39,6 +39,8 @@
#include "common-inferior.h"
#include "job-control.h"
#include "environ.h"
+#include "filenames.h"
+#include "pathstuff.h"
#include "common/selftest.h"
@@ -56,6 +58,10 @@
break; \
}
+/* String containing the current directory (what getwd would return). */
+
+char *current_directory;
+
/* The environment to pass to the inferior when creating it. */
static gdb_environ our_environ;
@@ -279,6 +285,23 @@ get_environ ()
return &our_environ;
}
+/* Verify if PROGRAM_NAME is an absolute path, and perform path
+ adjustment/expansion if not. */
+
+static void
+adjust_program_name_path ()
+{
+ /* Make sure we're using the absolute path of the inferior when
+ creating it. */
+ if (!IS_ABSOLUTE_PATH (program_name))
+ {
+ char *tmp_program_name = program_name;
+
+ program_name = gdb_abspath (program_name).release ();
+ xfree (tmp_program_name);
+ }
+}
+
static int
attach_inferior (int pid)
{
@@ -3012,6 +3035,8 @@ handle_v_run (char *own_buf)
program_name = new_program_name;
}
+ adjust_program_name_path ();
+
/* Free the old argv and install the new one. */
free_vector_argv (program_args);
program_args = new_argv;
@@ -3539,6 +3564,13 @@ captured_main (int argc, char *argv[])
const char *selftest_filter = NULL;
#endif
+ current_directory = getcwd (NULL, 0);
+ if (current_directory == NULL)
+ {
+ warning (_("%s: error finding working directory"),
+ safe_strerror (errno));
+ }
+
while (*next_arg != NULL && **next_arg == '-')
{
if (strcmp (*next_arg, "--version") == 0)
@@ -3759,6 +3791,8 @@ captured_main (int argc, char *argv[])
program_args.push_back (xstrdup (next_arg[i]));
program_args.push_back (NULL);
+ adjust_program_name_path ();
+
/* Wait till we are at first instruction in program. */
create_inferior (program_name, program_args);
@@ -4279,6 +4313,8 @@ process_serial_event (void)
/* Wait till we are at 1st instruction in prog. */
if (program_name != NULL)
{
+ adjust_program_name_path ();
+
create_inferior (program_name, program_args);
if (last_status.kind == TARGET_WAITKIND_STOPPED)
new file mode 100644
@@ -0,0 +1,54 @@
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2018 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test that gdbserver performs path expansion/adjustment when we
+# provide just a filename (without any path specifications) to it.
+
+load_lib gdbserver-support.exp
+
+standard_testfile normal.c
+
+if { [skip_gdbserver_tests] } {
+ return 0
+}
+
+# We only test things locally, and on native-gdbserver
+if { [is_remote target] || [is_remote host] || ![use_gdb_stub] } {
+ return 0
+}
+
+if { [prepare_for_testing "failed to prepare" $testfile $srcfile debug] } {
+ return -1
+}
+
+set target_exec [gdbserver_download_current_prog]
+set target_execname [file tail $target_exec]
+# We temporarily copy the file to our current directory
+file copy -force $target_exec [pwd]
+set res [gdbserver_start "" $target_execname]
+
+set gdbserver_protocol [lindex $res 0]
+set gdbserver_gdbport [lindex $res 1]
+gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
+
+if { [runto_main] } {
+ pass "load filename without absolute path"
+} else {
+ fail "load filename without absolute path"
+}
+
+file delete -force "[pwd]/$target_execname"
@@ -48,7 +48,7 @@ expect {
}
# Likewise, but with startup-with-shell enabled, which is the
# default behaviour.
- -re "stdin/stdout redirected.*exec: non-existing-program: not found\r\nDuring startup program exited with code 127\.\r\nExiting\r\n$" {
+ -re "stdin/stdout redirected.*: .*non-existing-program: No such file or directory\r\nDuring startup program exited with code 127\.\r\nExiting\r\n$" {
set saw_exiting 1
exp_continue
}