tag 28847 notabug
thanks
On 10/15/2017 02:58 AM, kakaxixi777 wrote:
>Dear coreutils :
>I am a Research and Development Engineer in IT. I met a situation when
>I use “sort” command in Linux shell which could be a bug for the "sort"
>command. So I hope you read this email, thank you
Sorry maybe I didn't speak clearly, I want to sort on the whole line by
each character from left to right, not only the 5 fields。
And why I use the same command "sort test.txt" and same input
"test.txt" on the 2016 Mac pro or on the windows10 , the result both
are :
forcemerge 28846 28847
tag 28846 notabug
close 28846
stop
On 15/10/17 01:03, Tree Big wrote:
> Dear coreutils :
> I am a Research and Development Engineer in IT. I met a situation when I
> use “sort” command in Linux shell which could be a bug for the "sort"
> command. So I hope you read this
Dear coreutils :
I am a Research and Development Engineer in IT. I met a situation when
I use “sort” command in Linux shell which could be a bug for the "sort"
command. So I hope you read this email, thank you !
The whole command I used was ：
sort test.txt
And the result was :
Dear coreutils :
I am a Research and Development Engineer in IT. I met a situation when I
use “sort” command in Linux shell which could be a bug for the "sort"
command. So I hope you read this email, thank you !
The whole command I used was ：
*sort test.txt*
*And the result was :*
Hi team,
I found this bug maybe I am lazy to look through the info document.
Correct:
$ TZ=UTC date -d 15:00 BST
Mon May 26 14:00:00 UTC 2014
Correct:
$ TZ=UTC date -d 15:00 EST
Mon May 26 20:00:00 UTC 2014
Correct:
$ TZ=UTC date -d 15:00 JST (Japan
tag 17600 notabug
close 17600
stop
On 05/26/2014 09:45 AM, HoHo Zhao wrote:
Hi team,
I found this bug maybe I am lazy to look through the info document.
Correct:
$ TZ=UTC date -d 15:00 BST
Mon May 26 14:00:00 UTC 2014
Correct:
$ TZ=UTC date -d 15:00 EST
Mon
HoHo Zhao wrote:
Wrong:
$ TZ=UTC date -d 15:00 CST (China Standard Time)
Mon May 26 21:00:00 UTC 2014
So the problem is with CST in the date STRING.
CST in the above is being interpreted as US Central Standard Time.
For Central Standard Time it is correct.
CST is one of the
Thank you Bob. I got it clear.
On 2014/5/27 10:55, Bob Proulx wrote:
HoHo Zhao wrote:
Wrong:
$ TZ=UTC date -d 15:00 CST (China Standard Time)
Mon May 26 21:00:00 UTC 2014
So the problem is with CST in the date STRING.
CST in the above is being interpreted as US Central
tags 10442 notabug
On 01/06/2012 10:58 AM, Andreas Schwab wrote:
yukuan yuk...@huawei.com writes:
When I user tail -f FILENAME to follow a file, which is continually
growing, the output sometimes stops. When I press ctrl-c to quit and right
immediately follow the same file, output would
When I user tail -f FILENAME to follow a file, which is continually growing,
the output sometimes stops. When I press ctrl-c to quit and right immediately
follow the same file, output would continue. And I found the file is growing
while the output stops.
(BTW, it's a log file with timestamp,
On 01/06/2012 07:27 AM, yukuan wrote:
When I user tail -f FILENAME to follow a file, which is continually
growing, the output sometimes stops. When I press ctrl-c to quit and right
immediately follow the same file, output would continue. And I found the file
is growing while the output
yukuan yuk...@huawei.com writes:
When I user tail -f FILENAME to follow a file, which is continually
growing, the output sometimes stops. When I press ctrl-c to quit and right
immediately follow the same file, output would continue. And I found the file
is growing while the output stops.
Why does head accept die option -1 and tail does not, in this same
context?
$ head -1 LottoDate.txt LottoJahr.txt LottoZahl.txt
== LottoDate.txt ==
09.10.1955 3 12 13 16 23 41
== LottoJahr.txt ==
1955 3 12 13 16 23 41
== LottoZahl.txt ==
3 12 13 16 23 41
$ tail -1 LottoDate.txt
On Fri, 21 Dec 2007, [EMAIL PROTECTED] wrote:
Why does head accept die option -1 and tail does not, in this same
context?
Please see this FAQ entry regarding arguments to tail:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails
I'm not sure why head
DecimalHi,
I used du in 2 formats, and the number os bytes doesn't correspond to the
number os megabytes.
Shouldn't i have another value for the 2du -sb ?
The value for the du -sm is the correct value.
Jorge Bastos
flecha:/home/alojamento/inducar.pt# du -sb .
80066621.
Jorge Bastos - Decimal [EMAIL PROTECTED] writes:
I used du in 2 formats, and the number os bytes doesn't correspond to the
number os megabytes.
As du --help explains, du -b is not the same thing as
du --block-size=1. It also sets the --apparent-size option,
which explains the discrepancy you
nosair wrote:
scp -r [EMAIL PROTECTED]:~/* ~/ECEJUNE2006 | tee transfer_june_2006.txt
I get the prompt for password. After that, the downloading of files and
folders begins as normal. However, the file transfer information does not show
on screen, and transfer_june_2006.txt remains empty
nosair wrote:
I executed the following command in bash:
scp -r [EMAIL PROTECTED]:~/* ~/ECEJUNE2006 | tee transfer_june_2006.txt
Thanks for the report. But this is not the SSH list. This is the GNU
coreutils list. 'scp' is not part of GNU coreutils. Assuming that
you are using OpenSSH then
19 matches
Mail list logo
