On 17/04/15 12:45, Erik Auerswald wrote:
On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote:
On 04/17/2015 10:39 AM, Ma Jiehong wrote:
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to say
the following:
cp [OPTION] SOURCE DEST
mv [OPTION] SOURCE DEST
On 04/17/2015 02:45 PM, Pádraig Brady wrote:
ln [OPTIONS] EXISTING NEW
I stilll think this is a translation issue.
And I don't think the synopsis has to look the same as for
cp and mv. If you really want it to be changed, What about
ln [OPTIONS] LINK_TARGET LINK_NAME
?
Have a nice
On Fri, Apr 17, 2015 at 01:45:02PM +0100, Pádraig Brady wrote:
On 17/04/15 12:45, Erik Auerswald wrote:
On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote:
On 04/17/2015 10:39 AM, Ma Jiehong wrote:
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to
say
On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote:
On 04/17/2015 10:39 AM, Ma Jiehong wrote:
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to say
the following:
cp [OPTION] SOURCE DEST
mv [OPTION] SOURCE DEST
ln [OPTIONS] TARGET LINK_NAME
Which is
Hello,
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to
say the following:
cp [OPTION] SOURCE DEST
mv [OPTION] SOURCE DEST
ln [OPTIONS] TARGET LINK_NAME
Which is the same exact rule, and is consistent.
While this is perfect for 'cp' and 'mv', I claim that it shouldn't
On 04/17/2015 10:39 AM, Ma Jiehong wrote:
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to say the
following:
cp [OPTION] SOURCE DEST
mv [OPTION] SOURCE DEST
ln [OPTIONS] TARGET LINK_NAME
Which is the same exact rule, and is consistent.
While this is perfect for 'cp'
On Fri, Apr 17, 2015 at 03:07:50PM +0200, Bernhard Voelker wrote:
On 04/17/2015 02:45 PM, Pádraig Brady wrote:
ln [OPTIONS] EXISTING NEW
I stilll think this is a translation issue.
And I don't think the synopsis has to look the same as for
cp and mv. If you really want it to be changed,
On 04/17/2015 11:03 AM, Peng Yu wrote:
On Fri, Apr 17, 2015 at 11:26 AM, Eric Blake ebl...@redhat.com wrote:
On 04/17/2015 10:10 AM, Peng Yu wrote:
Hi, I got the following results when I call sort with -t /. It seems
that 'a/1.txt' should be right after 'a'. Is it the case? Or I am not
using
On 04/17/2015 10:10 AM, Peng Yu wrote:
Hi, I got the following results when I call sort with -t /. It seems
that 'a/1.txt' should be right after 'a'. Is it the case? Or I am not
using sort correctly?
Your assumption is correct - you are using sort incorrectly, by failing
to take locales into
On Fri, Apr 17, 2015 at 11:26 AM, Eric Blake ebl...@redhat.com wrote:
On 04/17/2015 10:10 AM, Peng Yu wrote:
Hi, I got the following results when I call sort with -t /. It seems
that 'a/1.txt' should be right after 'a'. Is it the case? Or I am not
using sort correctly?
Your assumption is
I have compiled my own 'sort' which deliberately ignores
locale, (more precisely deliberately uses the 'C' locale
by default) for exactly this reason. I don't want to
screw with an environment variable that affects dozens
of things just to get sort to work predictably.
A while ago I offered a
* src/dircolors.hin: Add the MISSING entry, to indicate
this as a possibility in new templates output from dircolors,
and also to ease comparison with existing databases that
generally do define a MISSING entry.
---
src/dircolors.hin | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Hi, I got the following results when I call sort with -t /. It seems
that 'a/1.txt' should be right after 'a'. Is it the case? Or I am not
using sort correctly?
$ printf '%s\n' a 'a!' ab aB a/1.txt | sort -t / -k 1 -k 2 -k 3 -k 4
a
a!
a/1.txt
aB
ab
--
Regards,
Peng
13 matches
Mail list logo
