Paul Eggert, on Wed 16 Nov 2016 17:25:18 -0800, wrote:
> On 11/16/2016 05:07 PM, Pádraig Brady wrote:
> >we copy the directory but not the contents.
> >I'll adjust to:
> >
> > "not recursing; omitting directory '/foo/bar'"
> >
> How about using the traditional wording, e.g., Solaris?
>
> $ cp /e
Pádraig Brady, on Thu 17 Nov 2016 01:07:36 +, wrote:
> I agree, though we have to be careful not to imply
> we copy the directory but not the contents.
> I'll adjust to:
>
> "not recursing; omitting directory '/foo/bar'"
Perhaps
"not recursing by default, thus omitting directory '/foo/ba
Hello,
Every year, my students are completely taken aback when trying to copy a
directory:
$ cp /foo/bar .
omitting directory /foo/bar
The problem is that the error message is not explicit at all about what
issue cp actually encountered: "yes it is a directory, so what?!"
Could this be changed
Eric Blake, le Tue 08 May 2012 12:54:08 -0600, a écrit :
> On 05/08/2012 12:39 PM, Samuel Thibault wrote:
> > The misc/nice test currently fails on hurd-i386 because the nice support
> > there is not precise enough: the Mach kernel, which handles scheduling
> > priorities,
Eric Blake, le Tue 08 May 2012 12:46:57 -0600, a écrit :
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
> O_NOFOLLOW
> If path names a symbolic link, fail and set errno to [ELOOP].
>
> I wouldn't object to yet another O_* flag that can be used to disable
> translators,
(From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670477 )
Hello,
The misc/nice test currently fails on hurd-i386 because the nice support
there is not precise enough: the Mach kernel, which handles scheduling
priorities, has only 32 priority levels, and not 40, so conversion is
used, but th
Hello,
(From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670478 )
cp/parent-perm-race tries to copy a fifo with the --copy-contents
option. The problem is that cp still uses O_NOFOLLOW in that case,
strace shows:
open("mode/fifo", O_RDONLY|O_NOFOLLOW)
O_NOFOLLOW is actually normally meant
Hello,
Since some time, coreutils fails in split tests on GNU/Hurd. More
precisely, these two:
split/filter:55
split --filter="head -c1 >/dev/null" -n 1 /dev/zero
split/l-chunk:39
split -n l/2 /dev/zero
It seems that these two tests assume that split will stop by itself when
given /dev/zero as
Pádraig Brady, le Sat 10 Apr 2010 16:33:07 +0100, a écrit :
> On 10/04/10 01:28, Heinrich Langos wrote:
> > a) "dd" will maintain an existing of=target file including the inode
> >number, thus respecting existing hard links. "cp" will depending
> >on the other options given (e.g. "-a") ma
Pádraig Brady, le Fri 20 Mar 2009 12:23:29 +, a écrit :
> Samuel Thibault wrote:
> > $ ls -l
> > drwxr-xr-x 5 samy samy 4,0K mars 17 22:33 tmp/
> > drwx-- 5 samy samy 4,0K févr. 12 18:20 u/
> >
> > Because in the fr_FR locale abmon does not have a cons
Hello,
$ ls -l
drwxr-xr-x 5 samy samy 4,0K mars 17 22:33 tmp/
drwx-- 5 samy samy 4,0K févr. 12 18:20 u/
Because in the fr_FR locale abmon does not have a constant width, the
content of ls -l is misaligned. Locale standards require abday to have
a constant width, but that does not apply to
Andreas Schwab, le Sun 30 Dec 2007 12:32:06 +0100, a écrit :
> Samuel Thibault <[EMAIL PROTECTED]> writes:
> > Andreas Schwab, le Sun 30 Dec 2007 10:19:54 +0100, a écrit :
> >> Samuel Thibault <[EMAIL PROTECTED]> writes:
> >> > Some time ago, I wrote a
Andreas Schwab, le Sun 30 Dec 2007 10:19:54 +0100, a écrit :
> Samuel Thibault <[EMAIL PROTECTED]> writes:
> > Some time ago, I wrote a conv=sparse option for dd, attached is the
> > patch.
>
> How is it different from cp --sparse=always?
Uh, I hadn't noticed
Hello,
Some time ago, I wrote a conv=sparse option for dd, attached is the
patch. The goal is to recreate a sparse file from a file with 0s.
Typically, I use it to do this:
# mount /dev/hda6 /mnt/mnt
# dd bs=1M < /dev/zero > /mnt/mnt/foo
# rm -f /mnt/mnt/foo
# umount /mnt/mnt
# dd bs=1M conv=spa
14 matches
Mail list logo
