s from
running anything like a Web server).
I'm well aware that the above is reasonably dense and impenetrable, and
not especially helpful for diagnosing the problem, but I've been trying
to express it better for quite some time now and I'd rather get
something out there and be able to expan
Andreas Schwab wrote:
The Wanderer <[EMAIL PROTECTED]> writes:
I have a text file whose lines each contain two dates, of the
format "MM-DD-". I want to sort these lines into order from
oldest to most recent - that is, first by , then by MM, then by
DD. After I pars
Eric Blake wrote:
According to The Wanderer on 12/4/2005 9:56 AM:
I would suggest that it might be a good idea to provide a more
detailed explanation of this behaviour in the documentation. From
the man page, I did not even figure out that "the whitespace
between the fields belongs t
Brian Dessent wrote:
The Wanderer wrote:
I had considered that, but did not have a clear idea of what to add
or where to add it... and, now that I've both thought about that
further and looked more closely, the copy of the source I have
(from Debian's 5.93 source package) does not
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
According to The Wanderer on 12/6/2005 11:26 AM:
Actually, I'm looking at sort, not at rm
Sorry about that - I've been mixing threads in my mind.
No worries.
- and I'd already discovered the usage() functio
aining the situation.
If there's anything wrong with or otherwise objectionable about this,
don't hesitate to let me know; I'll either fix it if I can or attempt to
explain why I don't think it's a problem.
--
The Wanderer
Warning: Simply because I argue an issue does n
'test' and '[' are identical (actually, on my system, the
latter is a symlink to the former) but their behaviour differs. I'm
not sure how best to fix it.
(Hmm. A possible unintended behaviour in 5.93: '[ ] --help', rather than
exiting silently or printing the usage m
Jim Meyering wrote:
The Wanderer <[EMAIL PROTECTED]> wrote:
I was tripped up by the fact that it is not indicated anywhere in
the provided documentation that the character count of a field, for
the '-k' option, is counted from the beginning of the preceding
whitespace. The att
at "usually" applies.
According to The Wanderer on 12/8/2005 11:55 PM:
As it happened, I had also tried '[ ] ] --help', and got the same
message - but presumably this can be explained in the same way. It
somehow seems a little weird that such fundamental programs don't
per
Paul Eggert wrote:
The Wanderer <[EMAIL PROTECTED]> writes:
Hmm. Speaking of echo and its requirements, is there any way to
have it print '-n', '-e' or '-E' in an instance where they are not
preceded on the line by anything which is not a recognized option?
o produced the same effect, at
least in terms of timestamps being updated. I have made a few sporadic
tests beyond that, but none which have produced any new information.
If there's anything I can do to help resolve this, given an almost
complete lack of previous experience with programmin
On 12/22/2005 01:18 AM, Paul Eggert wrote:
The Wanderer <[EMAIL PROTECTED]> writes in
<http://lists.gnu.org/archive/html/bug-coreutils/2005-12/msg00199.html>:
I copied a directory hierarchy across a network to a shellfs mount,
What's a shellfs mount? Sorry, I've
On 12/22/2005 12:48 PM, Brian Dessent wrote:
The Wanderer wrote:
The strace output does not refer to utimes by name. The relevant
EPERM is returned by something referred to as SYS_271 - presumably
the label simply means "strace could not identify the name of this
syscall" - and a
On 12/28/2005 12:27 PM, Alfred M. Szmidt wrote:
sort -b not only ignores blanks, but also tabs.
A tab is a blank.
Perhaps it would be more clear to say "whitespace" instead. Or are there
types of whitespace other than 'spaces, tabs and newlines', which do not
get ig
ace" (since no other form of whitespace
produces a single column's worth of change), but there is no such thing
as "a single whitespace" in intuitive interpretation; "whitespace" is a
collective noun.
(May I also say, you have one of the stranger forms of quoting I'v
he same suggestion at the bottom. This is probably more a
Debian issue than a coreutils one, though.
--
The Wanderer is getting annoyed at having to continually re-enter
the E-mail address *twice* every time he replies to one of these messages...
Warning: Simply because I argue an issue d
ed past
experiences to be the intended way of producing a man page for any
coreutils program.
--
The Wanderer barely remembered to change the damn E-mail
addresses again...
Warning: Simply because I argue an issue does not mean I agree with any
sid
t is right and proper?
(Not that one shouldn't comply with that spec in the meantime - one
should - but acknowledging that "yes, the spec doesn't make any sense,
we'd prefer for it to be changed" seems like the bare minimum of sanity
to me.)
--
The Wanderer would
Paul Eggert wrote:
The Wanderer <[EMAIL PROTECTED]> writes:
common English usage suggests that the old behaviour is correct.
I suppose you might be able to talk me into that, but in that case we
need to fix the code and the documentation both. Any volunteers?
I don't have
art of the path to the file' (i.e., strip
everything prior to and including the final slash from the full path); I
do not especially care whether the option for either of these would be
short or long, but I would be appreciative if either were eventually
included.
--
The Wanderer
Warni
Bob Proulx wrote:
The Wanderer wrote:
For the little it's worth, I also find myself wanting to do
something like this from time to time, usually in a context in
which find is not a satisfactory alternative - or, at best, in
which it would be awkward and potentially difficult to constr
(I'm not entirely certain this still belongs on both lists... but I'm
also not sure that it doesn't.)
Bob Proulx wrote:
The Wanderer wrote:
What I was doing at the time, so far as I remember, was:
for i in `ls path/to/directory1/ path/to/directory2/` ; do ls -l $i
&&
copyright paperwork - which I consider an unnecessarily
burdensome requirement, at least to a point I haven't seen reached yet.)
--
The Wanderer STILL finds the refusal to behave like a proper
discussion forum offensive
Warning: Simply because I argue an issue does not mean I agr
discussion forum should,
and yet expect replies to ordinarily go back to the list anyway, it
might be a good idea for them to add a note in the automatic footer
reminding people to check the addresses when replying.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree
Jim Meyering wrote:
The Wanderer <[EMAIL PROTECTED]> wrote:
Eric Blake wrote:
Please keep replies on the list. I am not the maintainer, only
an interested party; so mailing me privately will have no effect
on the CVS repository.
A suggestion: if the people who administer this m
version or my more usual 5.97 (the latest in Debian
unstable), I cannot reproduce this; both forms of the switch work as
expected.
5.96:
==
[EMAIL PROTECTED]:/tmp$ rm -f file ; touch file
[EMAIL PROTECTED]:/tmp$ su -c 'ls file'
Password:
file
[EMAIL PROTECTED]:/tmp$ su --command '
mwoehlke wrote:
Jim Meyering wrote:
The Wanderer <[EMAIL PROTECTED]> wrote:
I appreciate the attitude, but frankly, I doubt it. The policy to
which I object is the practice of not automatically directing
replies to list messages back to the list - that is, the practice
of not putti
oth are correct, why are
two different terms used to describe the fact, when it would seem both
simpler and better to use the same terminology in parallel in both
cases?
--
The Wanderer does hope he hasn't just made a fool of himself in
public yet again
Warning: Simply beca
same time increment.
The counter-counterargument would be that since the actual
date-displaying code does treat daylight-savings-time days as being of
different lengths from others, the rest of the program should do the
same thing.
I'm not sure what the counters to that argument might be.
extra "coreutils/" in it - via links from
elsewhere on the site, but the behaviour does appear to exist
nonetheless.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
___
n shell scripts, and I've
written a few on-the-spot one-liners when I needed to pass tabs to
programs in this way.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Andreas Schwab wrote:
The Wanderer <[EMAIL PROTECTED]> writes:
Note also that this may not be possible in some shells
(specifically, so far as I've been able to discover, bash),
Of course it works in bash. You can enter every character literally
with C-v.
I've never used
and where and how to obtain it.
I get the same order with coreutils 6.7 as well.
I don't have coreutils 6.7 handy, but I'm grabbing the latest CVS code
now, and can build it and test with that (assuming that it runs properly
from its build location) if need be.
--
The Wand
more bleeding-edge than Debian unstable is, in this
respect.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
be no better answer available. However, that does leave the fact that
your typical user will not have any better idea of where to look for
help with a program than its own built-in help - and indeed some of them
may not even get that far.
--
The Wanderer
Warning: Simply because I argue an is
: I am interested in this more or less exclusively for
use on the command line. I do not care one way or the other about the
portability or lack thereof of scripts using such a feature.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it
(&*%&*!@ incorrect reply behaviour... I *hate* having to type out the
address by hand in every post.)
Bob Proulx wrote:
The Wanderer wrote:
It happens not infrequently that I want to sort or cut on the final
field of a sequence of lines which do not all have the same number
of fie
; I am also not unwilling to take further discussion offlist
entirely if the local bigwigs request it, although I would bring it back
on if anything resembling a conclusion in my favour were reached in
offlist discussion.
Bob Proulx wrote:
The Wanderer wrote:
(&*%&*!@ incorrect reply b
Bob Proulx wrote:
Matthew Woehlke wrote:
The Wanderer wrote:
However, it also had the side effect of producing null-terminated
lines, such that xargs could parse it cleanly even if the input
contained spaces. Without the ability to produce null-terminated
input segments, xargs will not work
minor degree of
effort devoted to the subject over time), imagine - any technical
obstacle to this which I have not been able to come up with a
comparatively trivial way to surmount.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy i
For all I know, there may be known reasons why this would not be all
that surprising, but it's different enough that I felt it worth
commenting on.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
41 matches
Mail list logo
