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 :
20171012|3|205
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 emai
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 :*
20171012|3|2059
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 U
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
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 ES
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" (J
tags 10442 notabug
On 01/06/2012 10:58 AM, Andreas Schwab wrote:
> yukuan 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.
yukuan 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.
Does it also
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
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,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Why does head accept die option -1 and tail does not, in this same
> context?
...
> $ LANG=C tail -1 LottoDate.txt LottoJahr.txt LottoZahl.txt
> tail: option used in invalid context -- 1
Thanks for the report.
What version of tail are you using?
Tha
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
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 Lotto
"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 di
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.
flecha:/hom
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 empt
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 th
Hello there,
I executed the following command in bash:
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 t
21 matches
Mail list logo
