On 07/27/2013 12:26 AM, Zahariev, Boris wrote:
The values for the same file-system differ depending on the file tested?
They shouldn't, no. What does 'strace' tell you about the
relevant system calls? If the system calls are reporting
the incorrect information, the bug lies in the kernel or
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'.
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
That format is typically considered to be erroneous, e.g.,
http://www.grammar.com/dates-day-month-year/, so I'm
not sure parse_datetime should be supporting it.
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
718...@bugs.debian.org
14...@debbugs.gnu.org
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
