I am still not convinced this is the ideal solution for Hurdiness.
But I'm not putting the time and effort into figuring out other
alternatives and what's adequate for what needs. You shouldn't let
me stand in the way of Hurd design changes, since I'm not actually
working on it this decade. If th
Hello,
Roland, could you have a look? This is really posing problems.
Samuel Thibault, le Fri 11 Apr 2014 09:03:03 +0200, a écrit :
As a reminder, here is the issue:
“
$ cat bar
#!/bin/sh
echo "\$0: $0"
$ cat foo.c
...
char *arg[] = { argv[1], NULL };
execv (*arg, arg);
Hello,
As a reminder, here is the issue:
“
$ cat bar
#!/bin/sh
echo "\$0: $0"
$ cat foo.c
...
char *arg[] = { argv[1], NULL };
execv (*arg, arg);
perror ("execv");
...
$ ./foo ./bar
$0: ./bar
$ ./foo bar
$0: /dev/fd/3
Having /dev/fd/N in $0 instead of the real file name
Hi,
On Fri, Jul 16, 2010 at 12:13:56PM +0200, Emilio Pozuelo Monfort wrote:
> On 31/05/10 18:27, Carl Fredrik Hammar wrote:
> > I have reviewed the patches and apart from formatting there were only
> > a couple of issues. Next iteration is hopefully the last.
>
> I hope so!
Almost. :-)
The bi
Hi,
On Wed, Jun 02, 2010 at 12:00:13AM +0200, olafbuddenha...@web.de wrote:
> Keep in mind that this convention stems from a time where people
> actually used to *print* code, on a 80 column line printer... So it was
> important to strictly observe the limit back then. Nowadays, screens are
> larg
Roland McGrath, le Tue 01 Jun 2010 16:22:57 -0700, a écrit :
> I am not convinced that this is worth doing. Any name from anywhere is
> always just a guess at what might be the right file name. There will
> always be cases where you can't manage to guess it.
That's why at least in the cases wher
On 02/06/10 01:22, Roland McGrath wrote:
> I am not convinced that this is worth doing. Any name from anywhere is
> always just a guess at what might be the right file name. There will
> always be cases where you can't manage to guess it. It is only a guess for
> convenience when not secure, aft
I am not convinced that this is worth doing. Any name from anywhere is
always just a guess at what might be the right file name. There will
always be cases where you can't manage to guess it. It is only a guess for
convenience when not secure, after all. With fexecve, there isn't even any
such
Hi Roland,
On 02/06/10 00:29, Roland McGrath wrote:
> wrt new RPC: sorry, I skipped the earlier discussion.
> What is this for?
No problem. Let me quote myself:
> Basically the problem is that in some cases the exec server can't find the
> file
> name of the file being executed (when it's a scr
wrt 80 columns max: just do it.
wrt new RPC: sorry, I skipped the earlier discussion.
What is this for?
Thanks,
Roland
Hi,
On Tue, Jun 01, 2010 at 11:39:42AM +0200, Carl Fredrik Hammar wrote:
> On Tue, Jun 01, 2010 at 03:52:59AM +0200, olafbuddenha...@gmx.net wrote:
> > On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote:
> > > Break these two lines. Try to stick to less than 76 columns or
> > >
Hi,
On Tue, Jun 01, 2010 at 03:52:59AM +0200, olafbuddenha...@gmx.net wrote:
> On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote:
> > On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote:
>
> > > +kern_return_t
> > > +S_exec_exec_file_name (struct trivfs_protid
Hi,
On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote:
> On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote:
> > +kern_return_t
> > +S_exec_exec_file_name (struct trivfs_protid *protid,
> > + file_t file,
> > + task_t oldtask
On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote:
> diff --git a/exec/exec.c b/exec/exec.c
> index 272b789..6b0f721 100644
> --- a/exec/exec.c
> +++ b/exec/exec.c
> @@ -1,5 +1,5 @@
> /* GNU Hurd standard exec server.
> - Copyright (C) 1992,93,94,95,96,98,99,2000,01,02,04
>
14 matches
Mail list logo
