[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Update of bug #28934 (project hurd): Wiki-like text discussion box: This got fixed with the addition of the *_exec_paths RPCs => ___ Follow-up Comment #15: This got fixed with the addition of the *_exec_paths RPCs

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Update of bug #28934 (project hurd): Status:None => Fixed Open/Closed:Open => Closed Wiki-like text discussion box: => This got fixed with the addition of the *_exec_pa

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Update of bug #28934 (project hurd): Wiki-like text discussion box: I've posted my last patches on http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html => ___ Follow-up Comment #14: I've posted my last

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Update of bug #28934 (project hurd): Wiki-like text discussion box: => I've posted my last patches on http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html ___ Reply to this item at:

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #13, bug #28934 (project hurd): Note that _hurd_exec() is exposed publicly by the glibc, used by ./utils/rpctrace.c: err = _hurd_exec (traced_task, file, argv, envp); for instance, so we can't arbitrarily add parameters.

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #12, bug #28934 (project hurd): The patch looks good, but I have a couple of suggestions. In __execve you cannot just call _hurd_exec_file_name unconditionally since all exec() variants end up as a __execve(). For instance, if there is both `/bin/foo' and `./foo', execpv("foo"

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #11, bug #28934 (project hurd): It looks like I somehow fucked the previous glibc build, since I've built it from scratch this time, and it works great. No regressions and gcc works. The patch was the same. I've modified the patch a little bit after testing that it works follow

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #10, bug #28934 (project hurd): Err the glibc patch was not the one I finally used (I attached the wrong one). Here's the one I've used. I've tested in another VM and I see the same regression. Furthermore I've found that gcc stops working fine in a machine with a new glibc.so

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #9, bug #28934 (project hurd): I don't see how the regression is possible given that the changes to the exec server should only affect shell scripts not C programs. Also your patch to glibc doesn't actually make use of _hurd_exec_file_name, which makes the above even more bizarr

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #8, bug #28934 (project hurd): Actually there seems to be a regression: a program like main (int argc, char **argv) { printf ("%s", argv[0]); } put into /bin/foobar, will make $ foobar print ./foobar instead of "foobar", which would be expected and works fine without my pat

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #7, bug #28934 (project hurd): The attached two patches fix this by adding a new exec flag in Hurd, EXEC_FILE_NAME, that will make the exec server to not look at PATH, but just exec the name it's been passed, even if it doesn't contain slashes. Then we add a new _hurd_exec_file

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Hi, On Fri, Feb 26, 2010 at 06:06:07PM +, Carl Fredrik Hammar wrote: > Giving them new names, e.g. _hurd_exec_path, might be a good idea to > avoid incompatibilities, but eventually we'll want to deprecate the > original versions. That's what I would suggest. > I don't know how this should

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

On Sat, Feb 27, 2010 at 09:40:55PM +0600, Ivan Shmakov wrote: > > Giving them new names, e.g. _hurd_exec_path, might be a good idea to > > avoid incompatibilities, > > FWIW, this seems to be the most reasonable solution to me. > > But note that there's a slight terminology issue here: > > --c

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

> Carl Fredrik Hammar writes: [...] >>> A final solution might be to change the exec protocol so that >>> exec*() can pass on the files path, which seems much more >>> robust. Or possibly do the checking for #!-scripts in glibc... But >>> you don't have to worry about this, unless you wa

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Hi, On Fri, Feb 26, 2010 at 10:18:27PM +0600, Ivan Shmakov wrote: > [I've unsuccessfully tried to submit the comment via the Web > interface at http://savannah.gnu.org/bugs/, thus I'm posting it > to the list instead.] No problem, people seem to mix the two all the time anyways.

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

[I've unsuccessfully tried to submit the comment via the Web interface at http://savannah.gnu.org/bugs/, thus I'm posting it to the list instead.] > Carl Fredrik Hammar writes: [...] > The reason argv[0] is expanded is because it is passed as an argument > to the i

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #6, bug #28934 (project hurd): > > The reason argv[0] is expanded is because it is passed as an argument > > to the interpreter, otherwise the interpreter can't find it. > > Unless it is a relative path, of course. I did mean any path, relative or not. What's important is tha

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #5, bug #28934 (project hurd): > The reason argv[0] is expanded is because it is passed as an argument > to the interpreter, otherwise the interpreter can't find it. Unless it is a relative path, of course. > Also, ``./foo bar'' gets me `bar' in Linux not `./bar'. Are you sur

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #4, bug #28934 (project hurd): I researched further how argv[0] is supposed to be handled and have a much firmer grasp on the situation now. argv[0] is only expanded to path to the executed file when the executed file is a #!-script. This means that touching argv[0] in execve(

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #3, bug #28934 (project hurd): Hi Carl, Actually I don't think the exec server needs to know what exec*() variant has been called, since the call itself will have called execve() with the full path by looking at PATH if needed (see glibc's posix/execvpe.c, the beginning of the

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #2, bug #28934 (project hurd): Hi Emilio, I'm pretty sure you are correct in that execve() should not look in $PATH, because glibc's sysdeps/mach/hurd/execve.c does a regular file lookup. As you say the exec server gets confused since it does not find bar in $PATH, and tries to

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #1, bug #28934 (project hurd): btw the POSIX standard that makes me think path in execve() should always be taken as a path (note the difference between path and file), from http://www.opengroup.org/onlinepubs/95399/functions/exec.html """ int execve(const char *path, char

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

URL: Summary: execve(path, args) should take path as a a relative path if it doesn't contain slashes Project: The GNU Hurd Submitted by: pochu Submitted on: Fri 19 Feb 2010 03:43:23 PM GMT