Bob Proulx wrote:
李嘉鹏 wrote:
I used some script(At the end of the letter) to get a series of
date. but the script always fails at the date 1991-04-14. so I
tested the single command
date -d '1991-04-14 +1 day'
It would also fail with a error message
date: invalid date
On 08/22/10 18:09, Alan Curry wrote:
There might be less occurrences of this misunderstanding if we could teach
date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
any time that existed during the day 4/14/1991, or perhaps a more specific
the first second of 4/14/1991.
mktemp: Please add an option which creates a fifo
instead of a file or a directory. --fifo seems appropriate,
although the abbreviation -f might be confused as a request
for an ordinary file; and -p as in --pipe is already taken
for prefix.
--
On 08/23/2010 09:22 AM, John Reiser wrote:
mktemp: Please add an option which creates a fifo
instead of a file or a directory. --fifo seems appropriate,
although the abbreviation -f might be confused as a request
for an ordinary file; and -p as in --pipe is already taken
for prefix.
Thanks
On 08/23/2010 09:40 AM, Eric Blake wrote:
On 08/23/2010 09:22 AM, John Reiser wrote:
mktemp: Please add an option which creates a fifo
[snip]
Thanks for the report. However, I'm inclined to mark this bug as a
duplicate of 6330, for the reasons already documented in this long thread:
On 08/23/2010 11:34 AM, John Reiser wrote:
On 08/23/2010 09:40 AM, Eric Blake wrote:
On 08/23/2010 09:22 AM, John Reiser wrote:
mktemp: Please add an option which creates a fifo
[snip]
Thanks for the report. However, I'm inclined to mark this bug as a
duplicate of 6330, for the reasons
On 19/08/10 16:51, Pádraig Brady wrote:
I also noticed differences with bind mounts though,
which I need to look into further.
There are also comments in df::show_point() to
indicate find_mount_points() is only a fall back and
may hang. Perhaps we need to move more of show_point()
to `stat`?
On 08/23/2010 11:00 AM, Eric Blake wrote:
[snip]
If we add 'mktemp --fifo', then where do we stop? What about creating a
uniquely named symlink? Or a new shared memory object?
There are several possible answers to Where do we stop?.
1) Stop at current code [no changes.]
2) Stop when user
On 08/23/2010 01:40 PM, John Reiser wrote:
Two independent user requests [one of which
includes code!] within a few months show a definite need.
The two requests would have been more convincing if they demonstrated
a definite need. Neither did: they both just said the equivalent
of we need a
Paul Eggert writes:
On 08/22/10 18:09, Alan Curry wrote:
There might be less occurrences of this misunderstanding if we could teach
date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
any time that existed during the day 4/14/1991, or perhaps a more specific
the
On 08/23/2010 02:59 PM, Alan Curry wrote:
date: invalid date `4/14/1991'
which is a lie. 4/14/1991 is not an invalid date.
It is an invalid date, under the assumption
that dates without times refer to the time 00:00:00
on that date. This assumption has been in the software
for ages, and
On 08/23/2010 02:22 PM, Paul Eggert wrote:
On 08/23/2010 01:40 PM, John Reiser wrote:
Two independent user requests [one of which
includes code!] within a few months show a definite need.
The two requests would have been more convincing if they demonstrated
a definite need. Neither did:
On 08/23/2010 04:49 PM, John Reiser wrote:
On 08/23/2010 02:22 PM, Paul Eggert wrote:
On 08/23/2010 01:40 PM, John Reiser wrote:
Two independent user requests [one of which
includes code!] within a few months show a definite need.
The two requests would have been more convincing if they
On 08/23/2010 03:55 PM, Eric Blake wrote:
We may be able to help you efficiently re-write your existing code into
an equally manageable but more portable solution using existing tools,
or it may help to convince us that the shorthand is truly useful.
I agree that a full example would be
There was a small memory leak in chown-core.c in the describe_change
function that would occur in cases where memory was allocated to
spec_allocated, but is passed an invalid Change_status. In that case it gets
to the default case and simply aborted without ever deallocating the memory.
Is there
William Plusnick wrote:
There was a small memory leak in chown-core.c in the describe_change
function that would occur in cases where memory was allocated to
spec_allocated, but is passed an invalid Change_status. In that case it gets
to the default case and simply aborted without ever
16 matches
Mail list logo
