[ast-developers] When will the tree reopen for normal patches?

[ольга крыжановская]

I know every thing is currently focused on getting vmalloc and signal
support working. But when will the tree reopen for normal patches?
There are some, older, patches queued, which should be applied before
ast-ksh is declared for beta status. Also some new problems appeared,
which should get addressed (i.e. cd /dev/fd/$d no longer works, eregex
with in multi line patterns ksh do not work with escaped +, ...)

Olga

[David Korn]

cc: ast-developers at research.att.com
Subject: Re: [ast-developers] When will the tree reopen for normal patches?
--------

Post by ольга крыжановская
cd /dev/fd/$d no longer works

What do you mean that it no longer works, I just did
exec 9< /tmp
and was able to do
cd /dev/fd/9/foo
to change to /tmp/foo.

David Korn
dgk at research.att.com

[Cedric Blancher]

Post by David Korn
cc: ast-developers at research.att.com
Subject: Re: [ast-developers] When will the tree reopen for normal patches?
--------

Post by ольга крыжановская
cd /dev/fd/$d no longer works

What do you mean that it no longer works, I just did
exec 9< /tmp
and was able to do
cd /dev/fd/9/foo
to change to /tmp/foo.

/bin/ksh -c 'exec {n}</etc ; cd /dev/fd/$n/ ; true'
/bin/ksh: cd: /dev/fd/11/: [Bad address]

This has been reported to ast-developers at research.att.com several
times. Search for '[Bad address]'.

There were also requests for cd -f $n relative_path to allow relative
paths which go above the starting point of fd, e.g. cd -f $n ../../a/b
The other reason for cd -f $fd relative_path was that POSIX does not
standardise absolute paths and that bash and dash developers see it as
a cleaner API to openat() than using /dev/fd

Ced

[David Korn]

cc: ast-developers at research.att.com
Subject: Re: Re: [ast-developers] When will the tree reopen for normal patches?
--------

Can I test the patch for cd -f?
Wendy

ksh93 does not support cd -f, bug supports cd ~{fd}/rel_path.

David Korn
dgk at research.att.com

[David Korn]

cc: ast-developers at research.att.com
Subject: Re: Re: Re: [ast-developers] When will the tree reopen for normal patches?
--------

~{fd}/.. doesn't work. It returns the /proc/pid/fd directory and not
the parent of the directory opened via openat().

This is a bug which I will fix.

The bash and dash camps have already rejected ~{fd}/rel_path as "not
in the spirit of POSIX", and that implementing relative paths via
~{fd} creates too much code bloat.

Since ksh93 already supports exec {fd}< file, supporting ~{fd} fits
in naturally. I will consider adding -f fd, if bash and dash add it,
but it will be equivalent to ~{fd}/rel_path.

Wendy

David Korn
dgk at research.att.com

[Cedric Blancher]

Post by David Korn
cc: ast-developers at research.att.com
Subject: Re: Re: Re: [ast-developers] When will the tree reopen for normal patches?
--------

~{fd}/.. doesn't work. It returns the /proc/pid/fd directory and not
the parent of the directory opened via openat().

This is a bug which I will fix.

How should a fix work? ~{fd}/ extends to a /dev/fd/$fd/ or
/proc/pid/fd/$fd/ path, and then relpath is appended. if this is
passed to the kernel it will still be relative to a /dev/fd/$fd/ or
/proc/pid/fd/$fd/ path.

Caching the path on the shell side will NOT work because if the
directory $fd is pointing to moves (which is, like openat(), the
purpose we use the $fd directories for - keep track of moving
directories).

I don't see an option here.

Post by David Korn

The bash and dash camps have already rejected ~{fd}/rel_path as "not
in the spirit of POSIX", and that implementing relative paths via
~{fd} creates too much code bloat.

Since ksh93 already supports exec {fd}< file, supporting ~{fd} fits
in naturally. I will consider adding -f fd, if bash and dash add it,
but it will be equivalent to ~{fd}/rel_path.

it should work the same way if rel_path doesn't go above the directory
location specified by $fd. but I see no chance to fix this in case
rel_path goes above $fd. Doesn't work, never.

Ced

[Glenn Fowler]

Post by David Korn

~{fd}/.. doesn't work. It returns the /proc/pid/fd directory and not
the parent of the directory opened via openat().

This is a bug which I will fix.

The bash and dash camps have already rejected ~{fd}/rel_path as "not
in the spirit of POSIX", and that implementing relative paths via
~{fd} creates too much code bloat.

I don't understand the code bloat argument because I bet cd isn't the last thing
that people will want to add -f fd to
besides, shell already handles ~ (per posix) and ~{fd} would be one more
addition to that centralized code

Post by David Korn
Since ksh93 already supports exec {fd}< file, supporting ~{fd} fits
in naturally. I will consider adding -f fd, if bash and dash add it,
but it will be equivalent to ~{fd}/rel_path.

Wendy

David Korn
dgk at research.att.com
_______________________________________________
ast-developers mailing list
ast-developers at lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers