Re: FYI: bug-fix: cp would fail to write through a dangling symlink

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:

> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>>> Yes, it's total overkill for this application.  Another thing: we
>>> don't need to resolve internal symlinks, just the last one.
>>
>> Why would we want to resolve *any* of them, if we can get
>> the dir-fd, ent-name pair I mentioned?
>
> Sorry, I lost context; but I take your point to mean is that if the
> destination /x/y/z is a symlink to /a/b/c, and /a/b/c is a symlink to
> /d/e/f, and /d/e/f is not a symlink, then we want to open /d/e/f with
> O_EXCL.

In that case, yes.  However, all of those symlink values are absolute.
The tricky part comes when you have relative ones.
Imagine relative symlink chains
  1 -> ../2 -> ../3 -> ../4 -> ...
or
  a -> b/a -> b/a -> b/a

Each relative link is "relative" to its position in the file system
hierarchy, so you can't open the link value directly.

To construct the final referent you have to choose:

 1) either accumulate the full, relative name.
  Then, you can use open, but it may fail with ENAMETOOLONG.

 2) or traverse using *at functions and return the final dirfd,entname pair
  Then you can open via openat (dirfd, entname, flags), but only if
  all intermediate directories are readable.

 3) or use a hybrid approach:
  use *at functions when you can, else accumulate multiple components.
  Then, you lose only when there are so many/long components in
  consecutive, unreadable directories that an accumulated name ends
  up being longer than PATH_MAX.  Not likely.

Such symlink chains are unusual, and not generally useful:

  $ ( for i in $(seq 10); do ln -s b/a && mkdir b && cd b;done )
  $ find b
  b
  b/a
  b/b
  b/b/a
  b/b/b
  b/b/b/a
  b/b/b/b
  b/b/b/b/a
  b/b/b/b/b
  b/b/b/b/b/a
  b/b/b/b/b/b
  b/b/b/b/b/b/a
  b/b/b/b/b/b/b
  b/b/b/b/b/b/b/a
  b/b/b/b/b/b/b/b
  b/b/b/b/b/b/b/b/a
  b/b/b/b/b/b/b/b/b
  b/b/b/b/b/b/b/b/b/a
  b/b/b/b/b/b/b/b/b/b
  $ cat a
  cat: a: Too many levels of symbolic links
  [Exit 1]

[BTW, use "8" in place of "10" above, and cat fails with ENOENT on Linux.
 On Solaris 10, you can go up to 20 before getting ELOOP:
   cat: a: Number of symbolic links encountered during path name \
 traversal exceeds MAXSYMLINKS
]

So, at least on some systems, with such an example, there'd be no
need to do anything, because the initial open would fail with ELOOP,
and not ENOENT.  Hmm... this is reminiscent of the test that led to
remove.c's non-handling of ELOOP.

While with Linux's current low limit (even with 255-byte dir names),
you can't trigger ENAMETOOLONG, on Solaris 10 and the Hurd, you can.
So at least it is possible to write a test.

> We don't care whether /x or /x/y or /a or /a/b or /d or /d/e
> are symlinks.  But canonicalize.c cares, and does more work than we
> want.
>
>>> were based on some existing coreutils code that I think is wrong in
>>> this area as well.
>>
>> Oh!  Then I'll hunt for it tomorrow if you don't tell first.
>
> If you like, here's the code I have right now: look for the patches
> that replace XSTAT to see the problem areas.  The XSTAT part of this
> patch is clearly incorrect (it doesn't pass the test cases) but the
> rest of the patch feels "right" and I hope the XSTAT part is on the
> right track.  If I make further progress I'll let you know but I have
> to work on other stuff right now.

Thanks for taking the time.
At first glance this looks good.
As you say, it'll take some time (and more tests)
to do this properly.

> 2007-06-13  Paul Eggert  <[EMAIL PROTECTED]>
>   and Jim Meyering  <[EMAIL PROTECTED]>
>
>   * src/copy.c: Include "canonicalize.h".
>   (copy_reg): When following a symlink, used the followed name in
>   later chown etc. requests, so that the created file is affected,
>   rather than the symlink.  Use O_NOFOLLOW on source when not
>   dereferencing symlinks; this avoids a race.  Preserve errno
>   correctly when doing multiple open attempts on the destination.
>   Use canonicalize_filename_mode to follow the symlink, so that we
>   can always open with O_EXCL and avoid a race.
>   (copy_internal): Follow destination symlinks when copying a regular
>   file, regardless of whether following source symlinks, since POSIX
>   and tradition says we should always follow destination symlinks if
>   the system calls would ordinarily do so.
>   * src/cp.c (make_dir_parents_private): Likewise.
>
> THIS PATCH IS NOT CORRECT.  <-- (warning if you didn't read the above)


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Problem with wc

[Pat Robinson]

cat foo | wc -l 

 

works the first time but will hang on subsequent attempts (foo is a
ordinary text file).

 

cat foo | more 

 

works fine time after time

 

I'm running 6.9 coreutils on Windows XP x64

 

Thanks,

 

Pat

 

 

Pat Robinson

Software Test Engineer

Quantum Corporation

Tiered Storage Systems

8560 Upland Drive, Englewood, CO 80112

Tel: (720) 249-5750
Fax: (303) 792-2465

[EMAIL PROTECTED]  

www.quantum.com

 




The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

An error

[Dhruv Rangoonwala]

Hi,

I have tried to use the following command:

cat -b 

If the file have blank lines, this command does not eliminate it. It still
gives number to that blank line. Please check it.

--
Thanks and regards,
Dhruv V Rangunwala
201-680-8198
[EMAIL PROTECTED]
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: An error

[Johannes Findeisen]

Hi,

On Wed, 2007-06-13 at 16:47 -0400, Dhruv Rangoonwala wrote:
> Hi,
> 
> I have tried to use the following command:
> 
> cat -b 
> 
> If the file have blank lines, this command does not eliminate it. It still
> gives number to that blank line. Please check it.
> 

Which version of core-utils are you using? I can't reproduce it here.
Could it be that there are whitespaces in the "blank" lines?

Example:

[EMAIL PROTECTED]:~> cat -b fooo  






 1

 2  dfsdfs



[EMAIL PROTECTED]:~> 

The line numbered with "1" looks blank but has one whitespace at the
beginning so it's not blank...

Regards,
Johannes



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: An error

[James Youngman]

On 6/13/07, Dhruv Rangoonwala <[EMAIL PROTECTED]> wrote:

I have tried to use the following command:

cat -b 

If the file have blank lines, this command does not eliminate it. It still
gives number to that blank line. Please check it.


Arguably this is a documentation deficiency.   When used with -b, the
cat program numbers non-empty lines, as opposed to non-blank lines.
Lines containing only blanks are not empty and so are numbered:-

$ yes "" | head | cat -b










$ yes " " | head | cat -b
1
2
3
4
5
6
7
8
9
   10
$


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Problem with wc

[Bob Proulx]

Pat Robinson wrote:
> cat foo | wc -l 
> works the first time but will hang on subsequent attempts (foo is a
> ordinary text file).
> cat foo | more 
> works fine time after time

That is really strange.  I can't imagine what the problem would be in
that case.  It is almost like no EOF is being recieved when piping.

> I'm running 6.9 coreutils on Windows XP x64

Try this test:

  wc -l < foo

Does that hang?  Try this test.  Does this hang?

  cat foo | cat | more

I would really like to see the result of 'strace' on wc.

  strace wc -l < foo

But I don't think strace is available on your system.  If it were that
would trace the system calls made by the program and we would be able
to (hopefully) see what it is doing.  Obviously wc is not hanging for
others using the program so this must be something specific to your
system or to the binary compilation that you are using.  I am sorry
but I don't have any further suggestions.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: nohup feature request / Please fwd to Jim Meyering

[Phillip Susi]

Bob Proulx wrote:

NOT this:

  $* >>nohup.out.$name-$pid

But this:

  $* | sed "s/^/$name-$pid: /" >> nohup.out
  $* | sed "s/^/$timestamp: /" >> nohup.out


OH!  I see now... yea, that would require active participation.


  trap "" 1 15
  if test -t 2>&1  ; then
echo "Sending output to 'nohup.out'"
exec nice -5 $* >>nohup.out 2>&1
  else
exec nice -5 $* 2>&1
  fi

All that nohup does is to ignore SIGHUP and SIGTERM and redirect the
output if it is not already redirected.  Before job control this was
all that was needed to avoid a controlling terminal disconnection from
killing the process.  Unfortunately with job control a little more is
needed.


Trapping the signals in the shell does not trap them in the exec'd child 
program, so I don't see how this would work.




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: nohup feature request / Please fwd to Jim Meyering

[Micah Cowan]

Phillip Susi wrote:
>>   trap "" 1 15
>>   if test -t 2>&1  ; then
>>   echo "Sending output to 'nohup.out'"
>>   exec nice -5 $* >>nohup.out 2>&1
>>   else
>>   exec nice -5 $* 2>&1
>>   fi
>>
>> All that nohup does is to ignore SIGHUP and SIGTERM and redirect the
>> output if it is not already redirected.  Before job control this was
>> all that was needed to avoid a controlling terminal disconnection from
>> killing the process.  Unfortunately with job control a little more is
>> needed.
> 
> Trapping the signals in the shell does not trap them in the exec'd child
> program, so I don't see how this would work.

Untrue, actually: _handling_ the signals would not handle them in the
exec'd child (for obvious reasons), but POSIX requires blocked signals
to remain blocked after an exec.

Try the following:


#!/bin/sh
trap "" TSTP
exec yes > /dev/null


and then try suspending the program with ^Z, with and without the "trap"
line commented out. :)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: FYI: bug-fix: cp would fail to write through a dangling symlink

[Paul Eggert]

Jim Meyering <[EMAIL PROTECTED]> writes:

> Thanks for taking the time.
> At first glance this looks good.
> As you say, it'll take some time (and more tests)
> to do this properly.

It turns out the existing tests already catch problems in this area,
it's just that I think the tests are buggy

Here's a proposed patch for all this.  The basic idea is to use 'stat'
on a destination file only if we plan to copy to it as a regular file;
if we plan to do anything else with it (e.g., remove or rename it, or
create it as a directory or special file) we use 'lstat'.

This causes the behavior of 'cp' to change in some fairly obscure
cases that are covered in the tests.  So this proposed patch changes
the tests to match.

It also tries to document this issue better; it is a bit of a hairy
one.  To some extent the doc fix was the hardest part of the patch

2007-06-14  Paul Eggert  <[EMAIL PROTECTED]>

* NEWS: "cp" no longer considers a destination symlink to be the
same as the referenced file when copying links or making backups.
* src/copy.c (copy_reg): When following a symlink, used the
followed name in later chown etc. requests, so that the created
file is affected, rather than the symlink.  Use O_NOFOLLOW on
source when not dereferencing symlinks; this avoids a race.
Preserve errno correctly when doing multiple open attempts on the
destination.
(copy_internal): Follow destination symlinks only when copying a
regular file and only when we don't intend to remove or rename the
destination first, regardless of whether following source
symlinks; this is because since POSIX and tradition (e.g.,
FreeBSD) says we should ordinarily follow destination symlinks if
the system calls would ordinarily do so.
* src/copy.h (struct cp_options): Add comment that 'dereference'
is only for source files.
* src/cp.c (usage): Note that --derereference etc. are only for
source files.
(make_dir_parents_private): Follow symlinks, regardless of whether
--dereference is specified, because these are destination symlinks.
* tests/cp/same-file: Adjust tests to match revised behavior.
Filter out perror output since it might vary from host to host.
Use sed alone instead of also using echo.

2007-06-14  Paul Eggert  <[EMAIL PROTECTED]>

* doc/coreutils.texi (cp invocation): Document the behavior better when
the destination is a symlink.  Clarify source versus destination
symlinks.  Describe the new behavior for destination symlinks.

diff --git a/NEWS b/NEWS
index 9db7902..f1b81f0 100644
--- a/NEWS
+++ b/NEWS
@@ -18,7 +18,12 @@ GNU coreutils NEWS-*- 
outline -*-
 ** Bug fixes

   cp no longer fails to write through a dangling symlink
-  [bug introduced in coreutils-6.7]
+  [bug introduced in coreutils-6.7].  Also, 'cp' no longer considers a
+  destination symlink to be the same as the referenced file when
+  copying links or making backups.  For example, if SYM is a symlink
+  to FILE, "cp -l FILE SYM" now reports an error instead of silently
+  doing nothing.  The behavior of 'cp' is now better documented when
+  the destination is a symlink.

   cut now diagnoses a range starting with zero (e.g., -f 0-2) as invalid;
   before, it would treat it as if it started with 1 (-f 1-2).
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 4ba2fb9..eb6691d 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -6909,13 +6909,22 @@ By default, @command{cp} does not copy directories.  
However, the
 copy recursively by descending into source directories and copying files
 to corresponding destination directories.

-By default, @command{cp} follows symbolic links only when not copying
+When copying from a symbolic link, @command{cp} normally follows the
+link only when not copying
 recursively.  This default can be overridden with the
 @option{--archive} (@option{-a}), @option{-d}, @option{--dereference}
 (@option{-L}), @option{--no-dereference} (@option{-P}), and
 @option{-H} options.  If more than one of these options is specified,
 the last one silently overrides the others.

+When copying to a symbolic link, @command{cp} normally follows the
+link when creating or copying to a regular file, even if the link is
+dangling.  However, @command{cp} does not follow these links when
+creating directories or special files.  Also, when an option like
[EMAIL PROTECTED] or @option{--link} acts to rename or remove the
+destination before copying, @command{cp} renames or removes the
+symbolic link rather than the file it points to.
+
 By default, @command{cp} copies the contents of special files only
 when not copying recursively.  This default can be overridden with the
 @option{--copy-contents} option.
@@ -6995,10 +7004,10 @@ Equivalent to @option{--no-dereference 
--preserve=links}.
 @opindex --force
 Whe

Re: An error

[Micah Cowan]

Johannes Findeisen wrote:
> Hi,
> 
> On Wed, 2007-06-13 at 16:47 -0400, Dhruv Rangoonwala wrote:
>> Hi,
>>
>> I have tried to use the following command:
>>
>> cat -b 
>>
>> If the file have blank lines, this command does not eliminate it. It still
>> gives number to that blank line. Please check it.
>>
> 
> Which version of core-utils are you using? I can't reproduce it here.
> Could it be that there are whitespaces in the "blank" lines?

A quick an' easy way to check would be to view the output of:

  sed -n l 

which will show the end of each line with a "$". If the "$" is not flush
to the left of the terminal, you have blanks in that line.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: nohup feature request / Please fwd to Jim Meyering

[Phillip Susi]

Micah Cowan wrote:

Untrue, actually: _handling_ the signals would not handle them in the
exec'd child (for obvious reasons), but POSIX requires blocked signals
to remain blocked after an exec.

Try the following:


#!/bin/sh
trap "" TSTP
exec yes > /dev/null


and then try suspending the program with ^Z, with and without the "trap"
line commented out. :)


Interesting... I thought that exec reset all signal handlers to their 
default behavior...





___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

RE: Problem with wc

[Pat Robinson]

Bob,

The other forms work ok.   I do have strace and tried the command but it
works everytime running it through strace.

Pat

-Original Message-
From: Bob Proulx [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 14, 2007 10:07 AM
To: Pat Robinson
Cc: bug-coreutils@gnu.org
Subject: Re: Problem with wc

Pat Robinson wrote:
> cat foo | wc -l 
> works the first time but will hang on subsequent attempts (foo is a
> ordinary text file).
> cat foo | more 
> works fine time after time

That is really strange.  I can't imagine what the problem would be in
that case.  It is almost like no EOF is being recieved when piping.

> I'm running 6.9 coreutils on Windows XP x64

Try this test:

  wc -l < foo

Does that hang?  Try this test.  Does this hang?

  cat foo | cat | more

I would really like to see the result of 'strace' on wc.

  strace wc -l < foo

But I don't think strace is available on your system.  If it were that
would trace the system calls made by the program and we would be able
to (hopefully) see what it is doing.  Obviously wc is not hanging for
others using the program so this must be something specific to your
system or to the binary compilation that you are using.  I am sorry
but I don't have any further suggestions.

Bob



The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Problem with wc

[Bauke Jan Douma]

Pat Robinson wrote on 13-06-07 22:04:
cat foo | wc -l 

 


works the first time but will hang on subsequent attempts (foo is a
ordinary text file).


"First time" after what?

Is foo any one particular file which display the behaviour
exclusively to any other ordinary text files?  Or is it the
proverbial 'fill in your own name here' kind of oridinary
text file, i.e. /all/ ordinary text files that display this
behaviour?

If not, is bisecting foo an option, and running the parts
through the command to see which and when the behavior occurs?

bjd



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: nohup feature request / Please fwd to Jim Meyering

[Andreas Schwab]

Micah Cowan <[EMAIL PROTECTED]> writes:

> Untrue, actually: _handling_ the signals would not handle them in the
> exec'd child (for obvious reasons), but POSIX requires blocked signals
> to remain blocked after an exec.

trap "" is not about blocking a signal, but ignoring it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: nohup feature request / Please fwd to Jim Meyering

[Micah Cowan]

Andreas Schwab wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
> 
>> Untrue, actually: _handling_ the signals would not handle them in the
>> exec'd child (for obvious reasons), but POSIX requires blocked signals
>> to remain blocked after an exec.
> 
> trap "" is not about blocking a signal, but ignoring it.

Yeah, my terminology's apparently not so great today: "exec'd child" is
another goof (s/b "exec'd process").

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: An error

[Paul Eggert]

"James Youngman" <[EMAIL PROTECTED]> writes:

> Arguably this is a documentation deficiency.

I agree; here's a proposed patch.

2007-06-14  Paul Eggert  <[EMAIL PROTECTED]>

* doc/coreutils.texi (cat invocation): "Blank" lines actually mean
empty lines.
* src/cat.c (usage): Say that "nonblank" means nonempty.  Clarify
--squeeze-blank.

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index eb6691d..7290ab2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -1308,7 +1308,7 @@ Equivalent to @option{-vET}.
 @itemx --number-nonblank
 @opindex -b
 @opindex --number-nonblank
-Number all nonblank output lines, starting with 1.
+Number all nonempty output lines, starting with 1.

 @item -e
 @opindex -e
@@ -1330,8 +1330,9 @@ Number all output lines, starting with 1.
 @itemx --squeeze-blank
 @opindex -s
 @opindex --squeeze-blank
[EMAIL PROTECTED] squeezing blank lines
-Replace multiple adjacent blank lines with a single blank line.
[EMAIL PROTECTED] squeezing empty lines
+Suppress repeated adjacent empty lines; output just one empty line
+instead of several.

 @item -t
 @opindex -t
diff --git a/src/cat.c b/src/cat.c
index e100a14..a9580e8 100644
--- a/src/cat.c
+++ b/src/cat.c
@@ -100,11 +100,11 @@ Usage: %s [OPTION] [FILE]...\n\
 Concatenate FILE(s), or standard input, to standard output.\n\
 \n\
   -A, --show-all   equivalent to -vET\n\
-  -b, --number-nonblanknumber nonblank output lines\n\
+  -b, --number-nonblanknumber nonempty output lines\n\
   -e   equivalent to -vE\n\
   -E, --show-ends  display $ at end of each line\n\
   -n, --number number all output lines\n\
-  -s, --squeeze-blank  never more than one single blank line\n\
+  -s, --squeeze-blank  suppress repeated empty output lines\n\
 "), stdout);
   fputs (_("\
   -t   equivalent to -vT\n\
M ChangeLog
M doc/ChangeLog
M doc/coreutils.texi
M src/cat.c
Committed as c46293d0207ed91e86f4e25109bee6bb5af539ae


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

How to find character special files dependencies for a program or library?

[Martijn Ras]

Heya Folks,

Is there any way to find the character special files for a program or 
library? Similar to using ldd to find the libraries for a program ...


Mazzel,

Martijn.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils