bug#14972: cp docs should mention permissions result when destination already exists

[jidanni]

Fellows, I don't think
(info "(coreutils) cp invocation")
mentions how
$ touch m
$ cp m n
$ chmod 444 m
$ cp m n #THESE LINES
$ cp m p #MAKE DIFFERENT THINGS
$ ls -l
-r--r--r-- 1 jidanni jidanni 0 07-28 11:20 m
-rw-r--r-- 1 jidanni jidanni 0 07-28 11:21 n
-r--r--r-- 1 jidanni jidanni 0 07-28 11:21 p
All we read is

 In the absence of this option, each destination file is created
 with the mode bits of the corresponding source file, minus the
 bits set in the umask and minus the set-user-ID and set-group-ID
 bits.  *Note File permissions::.

So it says 'created', but doesn't mention what happens if the destination
already exists.

Yes I am deliberately not using -p here.

(This would also explain the mystery of how openssh-client: /usr/bin/scp works.)

$ cp --version
cp (GNU coreutils) 8.21

bug#14971: bug tracking numbers for split man page bug

[jidanni]

718...@bugs.debian.org
14...@debbugs.gnu.org

bug#14971: split man page table mushed

[jidanni]

Package: coreutils
Version: 8.21-1
File: /usr/share/man/man1/split.1.gz

.PP
CHUNKS may be:
N   split into N files based on size of input
K/N output Kth of N to stdout
l/N split into N files without splitting lines
l/K/N   output Kth of N to stdout without splitting lines
r/N like 'l' but use round robin distribution
r/K/N   likewise but only output Kth of N to stdout

becomes

   CHUNKS  may  be:  N   split into N files based on size of input K/N
   output Kth of N to stdout l/N split into N files without  splitting
   lines  l/K/Noutput  Kth  of N to stdout without splitting lines r/N
   like 'l' but use round robin distribution  r/K/Nlikewise  but  only
   output Kth of N to stdout

on the man page.

Tested with
# su - nobody -c 'man split'

bug#14613: [PATCH] Make parse_datetime (and therefore `date') handle 'DAY MONTH, YEAR'

[Sergio Durigan Junior]

On Saturday, July 27 2013, Paul Eggert wrote:

> That format is typically considered to be erroneous, e.g.,
> , so I'm
> not sure parse_datetime should be supporting it.

I wasn't aware parse_datetime followed a defined grammar.  And this
seems to be an English grammar idiosyncrasy, which is definitely not
familiar to me (not a native english speaker).

IMO, I don't really see a problem supporting an "erroneous English
grammar", since parse_datetime should probably not be so strict about it
and adapt to such small cases.

Anyway, just my opinion.

-- 
Sergio

bug#14613: [PATCH] Make parse_datetime (and therefore `date') handle 'DAY MONTH, YEAR'

[Paul Eggert]

That format is typically considered to be erroneous, e.g.,
, so I'm
not sure parse_datetime should be supporting it.

bug#14963: The values for the same file-system differ depending on the file tested

[Bob Proulx]

Zahariev, Boris wrote:
> 
>  ~]$ sudo df -h /nfs/eq-fas3240-001a/vol/a0content1/rcuvb/
> FilesystemSize  Used Avail Use% Mounted on
> eq-fas3240-001a:/vol/a0content1
>   549G  501M  549G   1% 
> /nfs/eq-fas3240-001a/vol/a0content1
> 
>  ~]$ sudo df -h /nfs/eq-fas3240-001a/vol/a0content1/rcuniverse/
> FilesystemSize  Used Avail Use% Mounted on
> eq-fas3240-001a:/vol/a0content1
>   380G  495M  380G   1% 
> /nfs/eq-fas3240-001a/vol/a0content1
> 
> 
> The values for the same file-system differ depending on the file tested?

Please try these:

  strace -o df.strace.out -v -e trace=statfs 
/nfs/eq-fas3240-001a/vol/a0content1/rcuvb/
  strace -o df.strace.out -v -e trace=statfs 
/nfs/eq-fas3240-001a/vol/a0content1/rcuniverse/

Then report back what they say.  (I assume that your system is using
statfs.  If that reports an invalid system call name then just report
all file system calls.)

  strace -o df.strace.out -v -e trace=file 
/nfs/eq-fas3240-001a/vol/a0content1/rcuvb/
  strace -o df.strace.out -v -e trace=file 
/nfs/eq-fas3240-001a/vol/a0content1/rcuniverse/

And if that fails then everything.

  strace -o df.strace.out -v /nfs/eq-fas3240-001a/vol/a0content1/rcuvb/
  strace -o df.strace.out -v /nfs/eq-fas3240-001a/vol/a0content1/rcuniverse/

If the file is large then please think of the list bandwidth and
compress it before sending it back.

Bob

bug#14613: [PATCH] Make parse_datetime (and therefore `date') handle 'DAY MONTH, YEAR'

[Sergio Durigan Junior]

Hi there,

I have a fix for this issue.  This fix touches Gnulib, but I am sending
it here anyway so you guys can test and make sure it works.

It basically adds a simple production on lib/parse-datetime.y to extend
it in order to correctly handle the proposed date format, i.e., '2 June,
2013'.  It works OK here, but I'd be glad if you could give it a test.
Comments are also obviously welcome.

Thanks,

-- 
Sergio

diff --git a/ChangeLog b/ChangeLog
index 4d73a26..d9d89ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2013-07-27  Sergio Durigan Junior  
+
+   * lib/parse-datetime.y (date): Add production to handle dates like
+   '27 July, 2013'.  Problem reported for coreutils by Chris F.A.
+   Johnson in .
+
 2013-07-09  Paul Eggert  
 
regex: port to --with-included-regex --enable-gcc-warnings non-threaded
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index 4dce7fa..675ba5c 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -535,6 +535,13 @@ date:
 pc->month = $2;
 pc->year = $3;
   }
+  | tUNUMBER tMONTH ',' tUNUMBER
+  {
+/* e.g. 2 June, 2013.  */
+pc->day = $1.value;
+   pc->month = $2;
+   pc->year = $4;
+  }
   | iso_8601_date
   ;