cp --parents requires path as destination, can it be made to take filename?

[Aaron Peterson]

Hi,  I just spent a few hours learning how to find files and got a cp
command up that looked like it should work..

I ran into a problem that was very tough to find the solution to though,

cp: with --parents, the destination must be a directory
Try `cp --help' for more information.

I have since found a promising lead that suggested using the dirname
command to solve my problem.. hours later that I wish I knew that.

anyway, is there some drastic reason why --parents doesn't work with a
full filename with filname and path?

btw, I need the paths

-T --parents seems like it should make it write to a file...


#!/bin/bash
DESTDIR="/media/disk/highpriority"

find -maxdepth 2 -type f -name '*' | while read line; do
DESTtail=`echo "$line" | cut -c 2-` ;
#echo cp -v "$line" "$DESTDIR$DESTtail";
cp -T --parents -v "$line" "$DESTDIR$DESTtail";
done


Thanks.


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

Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Jim Meyering wrote:
> Brian Dessent <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>>   local setvbuf='__attribute__ ((constructor)) void
>>> f () { setvbuf (stdout, NULL, _IOLBF, 0); }'
>>>   echo "$setvbuf" | gcc -s -include stdio.h -x c - -fPIC -shared \
>>> -o "$line_buffer_so"
>> Note that I named the function 'f()' for brevity in the example, but for
>> a general solution I worry that it should have a name that cannot clash
>> with any other global symbol in the program or any of its libraries.
>> One way of achieving this is to put it in an anonymous namespace, which
>> obliges the compiler to give it a guaranteed-unique name:
>>
>>   local setvbuf='namespace { __attribute__ ((constructor)) void
>> f () { setvbuf (stdout, NULL, _IOLBF, 0); } }'
>>   echo "$setvbuf" | gcc -s -include stdio.h -x c++ - -fPIC -shared \
>> -o "$line_buffer_so"
> 
> Nice.
> For my personal use, relying on g++ is fine.
> But if we end up adding a tool like Pádraig's proposed "stdbuf",
> I am inclined to use only C.  Why?  It's not that C++ support isn't
> mature, it's just that adding a requirement in _coreutils_ (even if
> only for this one program) on not just LD_PRELOAD but also on C++...
> seems like opening pandora's box.  Any target system must already
> have LD_PRELOAD support, so that may help by eliminating some of
> the older candidates.

Yep, this is what I'm doing :)
I know C++ quite well actually. Well enough to be very wary of it.
__attribute__ ((constructor)) is available since gcc 2.95.1 at least.
(10 years).

> 
> Guaranteed namespace anonymity would be nice, but initially it will be
> ok to sacrifice that, as long as we choose a function name that is long
> and random.

Yep, the function name is not user visible so we can give it
something sufficiently unique.

> 
> At least for starters, I'd rather build the new program only when gcc
> is available with __attribute__((constructor)) support.  Or some other
> C compiler, as long as we know how to do the same things with it.
> Keep it simple.  This is the *GNU* coreutils package, after all,
> so it's ok if certain extra-value features are initially available
> only on systems with GNU tools.

cheers,
Pádraig.


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

Re: dd: reblock failure -- sporadic failures

[Jim Meyering]

Bob Proulx <[EMAIL PROTECTED]> wrote:
> This seems very strange.  Periodically I have seen the dd reblock test
> fail.  It isn't a hard failure and that seems like a critical clue to
> me.  But it also seems quite strange.
>
>   http://buildbot.proulx.com:9000/i686-gnu-linux-full/builds/990/step-test/0
>
>   + dd bs=3 ibs=1 obs=1
>   ...
>   + diff -u err exp-no-reblock
>   --- err 2008-11-29 07:07:22.0 -0700
>   +++ exp-no-reblock   2008-11-29 07:07:21.0 -0700
>   @@ -1,3 +1,3 @@
>   -1+1 records in
>   -1+1 records out
>   +0+2 records in
>   +0+2 records out
>4 bytes (4 B) copied
>   + fail=1

Hi Bob,

This should fix it in most cases.
There will always be a race when the consumer can start
far later than the producer.

I demonstrated the failure locally by using a shorter sleep interval:

while :; do printf .;(echo x; sleep .01; echo y) \
  | dd bs=3 ibs=1 obs=1 2>&1 |grep -F '1+1 records in' && break; done
..\
..\
..\
..1+1 records in

Here's the fix in my queue:

>From 149a55b6ff4137668b9a945fa6cab30bdd7933ea Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Sun, 30 Nov 2008 18:43:55 +0100
Subject: [PATCH] tests: avoid occasional dd/reblock failure

* tests/dd/reblock: Sleep longer to avoid a race condition.
Reported by Bob Proulx.
---
 tests/dd/reblock |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tests/dd/reblock b/tests/dd/reblock
index 542529a..ef9e036 100755
--- a/tests/dd/reblock
+++ b/tests/dd/reblock
@@ -44,7 +44,10 @@ sed 's/,.*//' err > k && mv k err
 compare err exp-reblock || fail=1

 # Demonstrate that bs=N supersedes even following ibs= and obs= settings.
-(echo x; sleep .1; echo y) | dd bs=3 ibs=1 obs=1 > out 2> err || fail=1
+# Choosing a delay of 0.1 would result in an occasional lost race where
+# the consumer's first read would consume 3 bytes rather than the expected 2.
+# Not wanting to sleep a full second, I'll raise that to 0.3.
+(printf ab; sleep .3; printf cd) | dd bs=3 ibs=1 obs=1 > out 2> err || fail=1
 sed 's/,.*//' err > k && mv k err
 compare err exp-no-reblock || fail=1

--
1.6.0.4.1101.g642f8


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

[PATCH] remove explicit declaration of putenv, ...

[Jim Meyering]

FYI, I've just pushed this and the dd/reblock fix:

>From 57e2022b8d4fa6a2fbb420447705701535e58b0d Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Wed, 12 Nov 2008 11:02:50 +0100
Subject: [PATCH] remove explicit declaration of putenv, ...

* src/date.c: ... now that gnulib guarantees that it's in .
* src/env.c: Likewise.
---
 src/date.c |2 --
 src/env.c  |2 --
 2 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/src/date.c b/src/date.c
index e94de60..43e2005 100644
--- a/src/date.c
+++ b/src/date.c
@@ -38,8 +38,6 @@

 #define AUTHORS proper_name ("David MacKenzie")

-int putenv ();
-
 static bool show_date (const char *format, struct timespec when);

 enum Time_spec
diff --git a/src/env.c b/src/env.c
index 97bec71..fb9d793 100644
--- a/src/env.c
+++ b/src/env.c
@@ -91,8 +91,6 @@
   proper_name ("Richard Mlynarik"), \
   proper_name ("David MacKenzie")

-int putenv ();
-
 extern char **environ;

 static struct option const longopts[] =
--
1.6.0.4.1101.g642f8


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

FYI: 5 small changes

[Jim Meyering]

These are test-related, except the last one,
which is to avoid a warning.

>From b5b3690d069b0bd4a1d561a8c1b527768d067b5d Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Mon, 24 Nov 2008 10:03:25 +0100
Subject: [PATCH 1/5] tests: avoid failure of cp/link-heap on some systems

* tests/cp/link-heap: Raise virtual memory limit from 10,000
to 14,000, to avoid failure on Debian/unstable (libc6 2.7-16).
---
 tests/cp/link-heap |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/cp/link-heap b/tests/cp/link-heap
index b20c7d3..7aa142d 100755
--- a/tests/cp/link-heap
+++ b/tests/cp/link-heap
@@ -36,6 +36,6 @@ mkdir e || framework_failure
 mv $a $b e || framework_failure

 fail=0
-(ulimit -v 1; cp -al e f) || fail=1
+(ulimit -v 14000; cp -al e f) || fail=1

 Exit $fail
--
1.6.0.4.1101.g642f8


>From 847ab6a518b0e5d88f4e1aba29aa1caeef889fa2 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Fri, 28 Nov 2008 21:32:39 +0100
Subject: [PATCH 2/5] tests: start long-running cp/link-heap earlier

* tests/Makefile.am (TESTS): Move cp/link-heap nearer the start of the
list, so that its termination doesn't delay a parallel "make check".
---
 tests/Makefile.am |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8c768bb..307e5a8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -74,6 +74,7 @@ TESTS =   \
   misc/invalid-opt \
   rm/ext3-perf \
   rm/cycle \
+  cp/link-heap \
   chmod/no-x   \
   chgrp/basic  \
   rm/dangling-symlink  \
@@ -124,7 +125,7 @@ TESTS = \
   misc/ptx \
   misc/test\
   misc/seq \
-  misc/seq-long-double \
+  misc/seq-long-double \
   misc/head\
   misc/head-elide-tail \
   tail-2/tail-n0f  \
@@ -262,7 +263,6 @@ TESTS = \
   cp/file-perm-race\
   cp/into-self \
   cp/link  \
-  cp/link-heap \
   cp/link-no-deref \
   cp/link-preserve \
   cp/no-deref-link1\
--
1.6.0.4.1101.g642f8


>From d6a62182f07766296244ccc4f8c2d1a800e987bd Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Fri, 28 Nov 2008 22:08:09 +0100
Subject: [PATCH 3/5] build: don't reject definition of STREQ

* maint.mk (sc_prohibit_strcmp): Tighten rule: exclude
macro definitions like the one in system.h.
* .x-sc_prohibit_strcmp: Don't exempt src/system.h.
---
 .x-sc_prohibit_strcmp |1 -
 maint.mk  |3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.x-sc_prohibit_strcmp b/.x-sc_prohibit_strcmp
index fdceaf0..56631ab 100644
--- a/.x-sc_prohibit_strcmp
+++ b/.x-sc_prohibit_strcmp
@@ -1,2 +1 @@
-^src/system\.h
 ChangeLog
diff --git a/maint.mk b/maint.mk
index a7d0b86..cb3c6a5 100644
--- a/maint.mk
+++ b/maint.mk
@@ -132,7 +132,8 @@ sc_prohibit_atoi_atof:
 # Use STREQ rather than comparing strcmp == 0, or != 0.
 sc_prohibit_strcmp:
@grep -nE '! *str''cmp *\(|\&2; exit 1; } || :

--
1.6.0.4.1101.g642f8


>From 90f74735aa2f4753a3ae9cea848ef98daa31b7a6 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Sat, 29 Nov 2008 11:22:00 +0100
Subject: [PATCH 4/5] tests: df: skip total-verify if df fails

* tests/df/total-verify: Skip the test if df fails.
---
 tests/df/total-verify |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tests/df/total-verify b/tests/df/total-verify
index caf6d1a..ba27747 100755
--- a/tests/df/total-verify
+++ b/tests/df/total-verify
@@ -23,6 +23,8 @@ fi

 . $srcdir/test-lib.sh

+df || skip_test_ "df fails"
+
 cat <<\EOF > check-df || framework_failure
 my ($total, $used, $avail) = (0, 0, 0);
 while (<>)
--
1.6.0.4.1101.g642f8


>From b14e5c40b9e7f6140a800a0b69eec693ea73fd09 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Sun, 30 Nov 2008 17:39:11 +0100
Subject: [PATCH 5/5] m4: avoid a warning from gcc's -Wstrict-prototypes

* m4/jm-macros.m4 (ARGMATCH_DIE_DECL): Use proper prototype for usage.
---
 m4/jm-macros.m4 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4
index 8fa1740..a53be5b 100644
--- a/m4/jm-macros.m4
+++ b/m4/jm-macros.m4
@@ -38,7 +38,7 @@ AC_DEFUN([coreutils_MACROS],
   # By default, a

Re: dd: reblock failure -- sporadic failures

[Pádraig Brady]

Jim Meyering wrote:
> diff --git a/tests/dd/reblock b/tests/dd/reblock
> index 542529a..ef9e036 100755
> --- a/tests/dd/reblock
> +++ b/tests/dd/reblock
> @@ -44,7 +44,10 @@ sed 's/,.*//' err > k && mv k err
>  compare err exp-reblock || fail=1
> 
>  # Demonstrate that bs=N supersedes even following ibs= and obs= settings.
> -(echo x; sleep .1; echo y) | dd bs=3 ibs=1 obs=1 > out 2> err || fail=1
> +# Choosing a delay of 0.1 would result in an occasional lost race where
> +# the consumer's first read would consume 3 bytes rather than the expected 2.
> +# Not wanting to sleep a full second, I'll raise that to 0.3.
> +(printf ab; sleep .3; printf cd) | dd bs=3 ibs=1 obs=1 > out 2> err || fail=1
>  sed 's/,.*//' err > k && mv k err
>  compare err exp-no-reblock || fail=1

Doesn't the same logic need to be applied to both tests in this file,
as they both expect 2 short reads?

Hmm, I wonder is there a way to get the producer
to wait until the consumer is ready.
I think both open()s on a fifo block on each other,
so the following would cause `printf ab` to happen
after dd has executed open(), which might help?

mkfifo dd.fifo
dd ibs=3 obs=3 if=dd.fifo > out 2> err&
(printf ab; sleep .1; printf cd) > dd.fifo
wait #for dd to complete
sed 's/,.*//' err > k && mv k err
compare err exp-no-reblock || fail=1

thanks,
Pádraig.



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

Re: dd: reblock failure -- sporadic failures

[Jim Meyering]

Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> diff --git a/tests/dd/reblock b/tests/dd/reblock
>> index 542529a..ef9e036 100755
>> --- a/tests/dd/reblock
>> +++ b/tests/dd/reblock
>> @@ -44,7 +44,10 @@ sed 's/,.*//' err > k && mv k err
>>  compare err exp-reblock || fail=1
>>
>>  # Demonstrate that bs=N supersedes even following ibs= and obs= settings.
>> -(echo x; sleep .1; echo y) | dd bs=3 ibs=1 obs=1 > out 2> err || fail=1
>> +# Choosing a delay of 0.1 would result in an occasional lost race where
>> +# the consumer's first read would consume 3 bytes rather than the expected 
>> 2.
>> +# Not wanting to sleep a full second, I'll raise that to 0.3.
>> +(printf ab; sleep .3; printf cd) | dd bs=3 ibs=1 obs=1 > out 2> err || 
>> fail=1
>>  sed 's/,.*//' err > k && mv k err
>>  compare err exp-no-reblock || fail=1
>
> Doesn't the same logic need to be applied to both tests in this file,
> as they both expect 2 short reads?

Yes.  Good point.

> Hmm, I wonder is there a way to get the producer
> to wait until the consumer is ready.
> I think both open()s on a fifo block on each other,
> so the following would cause `printf ab` to happen
> after dd has executed open(), which might help?
>
> mkfifo dd.fifo
> dd ibs=3 obs=3 if=dd.fifo > out 2> err&
> (printf ab; sleep .1; printf cd) > dd.fifo
> wait #for dd to complete
> sed 's/,.*//' err > k && mv k err
> compare err exp-no-reblock || fail=1

Good idea.
That looks like a more reliable solution.
Do you feel like writing the patch?


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

[bug #24974] Document that comm's option "-1", "-2" and "-3" can be combined

[anonymous]

URL:
  

 Summary: Document that comm's option "-1","-2" and "-3" can
be combined
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Sun 30 Nov 2008 22:11:59 UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

Could you explicitly document that "-1", "-2" and "-3" options
of "comm" can be combined.
This isn't obvious, and may lead some people [me!] to use
other tools instead.

Thanks in advance

Franklin
fpiat @ klabs;be




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Re: [bug #24974] Document that comm's option "-1", "-2" and "-3" can be combined

[Pádraig Brady]

anonymous wrote:
> URL:
>   
> 
> Hello,
> 
> Could you explicitly document that "-1", "-2" and "-3" options
> of "comm" can be combined.
> This isn't obvious, and may lead some people [me!] to use
> other tools instead.

It's common for options to be combined unless otherwise stated,
but I take your point that it's perhaps a little confusing.
Perhaps this change would make it more obvious?
It's not removing info as the info removed is already
presented on the previous line.

diff --git a/src/comm.c b/src/comm.c
index 4ec7e4a..6f250a9 100644
--- a/src/comm.c
+++ b/src/comm.c
@@ -113,9 +113,9 @@ and column three contains lines common to both files.\n\
 "), stdout);
   fputs (_("\
 \n\
-  -1  suppress lines unique to FILE1\n\
-  -2  suppress lines unique to FILE2\n\
-  -3  suppress lines that appear in both files\n\
+  -1  suppress output of column 1\n\
+  -2  suppress output of column 2\n\
+  -3  suppress output of column 3\n\
 "), stdout);
   fputs (_("\
 \n\


I might add some examples to the docs also, along the lines
of the following if I get a second. At least I should get
the docs for `comm` and `join` to reference each other.

# set operations on sorted files

comm file1 file2 | sed 's/^\t*//' #Union
comm -12 file1 file2  #Intersection
comm -13 file1 file2  #Difference
comm -3 file1 file2 | sed 's/^\t*//'  #Symmetric Difference

join -a1 -a2 file1 file2  #Union
join file1 file2  #Intersection
join -v2 file1 file2  #Difference
join -v1 -v2 file1 file2  #Symmetric Difference

# set operations on unsorted files

sort file1 file2 | uniq   #Union
sort file1 file2 | uniq -d#Intersection
sort file1 file1 file2 | uniq -u  #Difference
sort file1 file2 | uniq -u#Symmetric Difference

cheers,
Pádraig.

p.s. Those new --check-order --nocheck-order options confuse me.
When they were added I only took a quick look at the implementation
rather than the interface (which Bo Borgerson kindly sped up for us).
Perhaps something like this would be clearer:

  --check-order={none,mismatch,unsorted}
  By default --check-order=mismatch is enabled.

I suppose it's too late to change now.


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

du --files-from feature request

[Aaron Peterson]

Hi,
A feature request for du,  a way to sum  from a list of files without
doing tr \n \0

I had to sort some files and and needed to know how large the group of
 files that I had found were.

I spend many hours trying to figure this out / and searching for solution.
It turns out that the \0 delimited list requirement was very painful.
I wish I could cat the output of find  into du and get the total

btw, my find options included restricting it to type file,

http://www.mail-archive.com/[EMAIL PROTECTED]/msg396774.html

Geraud suggests a mode for du to to avoid situations like this:


Example:
$ find  - >files.list
# create a NL-separated list of files
$ wc -l files.list
# wc could not be used to count NUL-separated items
# (another more complex program would be needed)
$ sed -i -e  files.list
# sed is designed for "regular" lines (NL-terminated)
$ wc -l files.list
$ emacs files.list
# editing a NUL-separated list in emacs would be inconvenient
$ tr $'\n' $'\0' files0.list
# an additional command that I would like not to type
$ du -csb --from-files0 files0.list | tail -n1
# note the additional tail command that also could be avoided
# if there were an option to only display the grand total
$ IFS=$'\n' for i in `cat files.list`; do archive "$i"; done
# if the list is not too long
# does not work with NUL-separated lists (or I do not know how)
$ xargs -n1 -d \\n --arg-file=files.list archive
# if the list is very long
# here files0.list could be used


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

Re: du --files-from feature request

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Aaron Peterson on 11/30/2008 5:16 PM:
> Hi,
> A feature request for du,  a way to sum  from a list of files without
> doing tr \n \0

Thanks for the report.  You didn't mention which version of du you are
using.  du has supported the option --files0-from since coreutils 5.3.0,
in 2005.  The latest stable version is 6.12, and beta 7.0 is also available.

> $ tr $'\n' $'\0' files0.list

This doesn't do what you think.  $'\0' is equivalent to the empty string,
not the string containing a NUL byte; you need '\0' (not $'\0') if you
want to manage NUL bytes with tr.  By the way, tr understands '\n', so you
don't have to resort to the less-portable $'\n'.

> $ du -csb --from-files0 files0.list | tail -n1
> # note the additional tail command that also could be avoided
> # if there were an option to only display the grand total

Oh, so you are asking for a way to show only the grand total, in addition
to --files0-from.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkzQKEACgkQ84KuGfSFAYA1qQCgq4Kc4YdkINnqEwW5cI528z/p
atEAoM2LQmxkKQRuDJrtq4tkgLDA/hnC
=MIvW
-END PGP SIGNATURE-


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

Re: du --files-from feature request

[Brian Dessent]

Aaron Peterson wrote:

> I spend many hours trying to figure this out / and searching for solution.
> It turns out that the \0 delimited list requirement was very painful.
> I wish I could cat the output of find  into du and get the total

It's meant to be used like:

$ find . -type f -print0 | du --files0-from=-

Note also that xargs takes -0 for the same reason:

$ find . -type f -print0 | xargs -0 command

Using tr is not the intended use pattern, as it completely misses the
point.  \0 is the only character that cannot be part of a filename
(other than '/'), so the only reliable way to deal with arbitrary
filenames without complicated quoting is to \0-delimit them.  Using tr
to convert newlines to \0 fails if you have filenames with newlines in
them, not to mention that it's pointless overhead.

Brian


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

[bug #24949] coreutils pwd not implementing latest POSIX features

[Paul D. Smith]

Follow-up Comment #2, bug #24949 (project coreutils):

The problem is that without -P I can't invoke pwd from things like Perl
portably.  If I use "my $pwd = `pwd`;" and it runs a shell and uses the shell
builtin version of pwd, then I get the wrong thing (I explicitly want the
"real" path; what POSIX defines "pwd -P" to return).

But on the other hand, if I use "my $pwd = `pwd -P`;", which is what a
correct POSIX-conforming script would do, and it runs coreutils pwd instead of
a shell builtin, I get a syntax error.

In short, this is a big drag.

It would be great if, at least, coreutils pwd handled the -P option (since
that's what it does by default it could just accept the option and behave as
it does now).  In other words, I think Reuben Thomas's solution here:
http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00259.html is
acceptable.

On the other hand, I think it would not actually be that difficult to
implement -L.  It seems to me that Eric Blake's description of what it would
take to adhere to the POSIX standard, as he describes here:
http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00258.html is more
complicated than necessary.  We do not need to strip "." or ".." from the
value of $PWD.  All we need to do is determine if the value of $PWD is (a) an
absolute path, and (b) it refers to the current directory, and (c) it does not
contain "." or ".." as filename elements.  Of these the only tricky bit AFAICS
is (b); we would need to do something like compare the device/inode values of
the directory pointed to by $PWD and the current directory to be sure they had
the same value.  I'm not sure if glib provides this type of functionality.

If all those conditions are met, then "pwd" and "pwd -L" print the value of
$PWD.  If any of those conditions are not met, or if the user asks for "pwd
-P", then we print the absolute pathname determined the same way we determine
it today.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Re: du --files-from feature request

[Pádraig Brady]

Aaron Peterson wrote:
> Hi,
> A feature request for du,  a way to sum  from a list of files without
> doing tr \n \0

Supporting --files-from would be less general.
Is `tr '\n' '\0'` that onerous?

> I had to sort some files and and needed to know how large the group of
>  files that I had found were.
> 
> I spend many hours trying to figure this out / and searching for solution.
> It turns out that the \0 delimited list requirement was very painful.
> I wish I could cat the output of find  into du and get the total

find -type f -print0 | du -c --files0-from=- | tail -n1

Having reviewed the docs I noticed that the most common
case of specifying '-' (stdin) to the --files0-from option
is not mentioned. So I just pushed this change to address that:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=00b5a2db33cddadf641ae2f01534514314d7e817

I also did a non user visible change to the info docs while I was
at it to standardize on using lower-case @var{file}:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1ce9d86c308d7daa6271a2e87629984b153ee9da

> # wc could not be used to count NUL-separated items
> # (another more complex program would be needed)

tr -d '\n' | tr '\0' ''\n' | wc -l

> $ xargs -n1 -d \\n --arg-file=files.list archive
> # if the list is very long
> # here files0.list could be used

xargs -0 ...

Pádraig.


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