James Youngman wrote:
> * gnulib: Update to latest.
> * src/system.h: Definitions of ST_* macros have moved into the
> gnulib module stat-size (specifically, the header file
> stat-size.h), so remove them from here.
> * src/truncate.c: Include stat-size.h.
> * src/stat.c: Likewise.
> * src/shred.c:
Hi all,
I was trying to search for any description helping me understand in what I
see, but actually I didn't find any, so I'm here. I discovered it by using
automake-1.11, because it uses relative paths a lot. So my simplified
testcase is as follows:
Have a directory structure x/y and x/z/a. Hav
Hi,
This behavior is normal. The key here is the .. link in each directory, it
always points to the parent directory.
For example, in your situation, the ".." in z is x, and it cannot be
something else.
Even if you access to z using the path x/y/z which use the symbolic link,
and then use ".." lin
On 06/13/2011 07:36 AM, Jim Meyering wrote:
> However, it looks like using "eval" didn't help at all.
> What does this do on that system?
>
> sh -c 'e=2; warn_ () { echo "$@" 1>&$e; }; warn_ x'
$ sh -c 'e=2; warn_ () { echo "$@" 1>&$e; }; warn_ x'
x
>
> This is what happens via tests/check.
Hi Loïc,
Dne pondělí 13 Červen 2011 16:51:54 Loïc Le Loarer napsal(a):
> Hi,
>
> This behavior is normal. The key here is the .. link in each directory, it
> always points to the parent directory.
> For example, in your situation, the ".." in z is x, and it cannot be
> something else.
> Even if y
Hi Oldřich,
2011/6/13 Oldřich Jedlička
> Dne pondělí 13 Červen 2011 16:51:54 Loïc Le Loarer napsal(a):
> > This behavior is normal. The key here is the .. link in each directory,
> it
> > always points to the parent directory.
> > For example, in your situation, the ".." in z is x, and it cannot
Hi Loïc,
Dne pondělí 13 Červen 2011 18:40:36 Loïc Le Loarer napsal(a):
> Hi Oldřich,
>
> 2011/6/13 Oldřich Jedlička
>
> > Dne pondělí 13 Červen 2011 16:51:54 Loïc Le Loarer napsal(a):
> > > This behavior is normal. The key here is the .. link in each directory,
> >
> > it
> >
> > > always poi
Eric Blake wrote:
> On 06/13/2011 09:37 AM, Jim Meyering wrote:
>>> But I think the reason that it invokes a problem is not because of the
>>> 1>&$e construct, but because HP-UX opens secondary file descriptors as
>>> cloexec or otherwise closing them at some point, so the '/bin/sh k'
>>> child pr
