I looked at the text version of the bug report and don't understand it.
Can you please rephrase the bug report so that you tell us how you
invoked 'paste' (command line arguments and input file contents), what
behavior you expected, and what behavior you observed? Please bear in
Forwarding this attachment to <66...@debbugs.gnu.org> as it got lost in
my spam inbox when it got sent just to me.
Forwarded Message
Subject: Re: bug#66294: Formal Bug Report in paste.c of Coreutils
Version 9.0 by Klee
Date: Mon, 02 Oct 2023 10:53:57 +000
Would you please resend your bug report as plain text? Thanks.
I missed the quote.
Sorry for my bad.
Kind regards
Am Sun, 04 Dec 2022 16:54:02 +
schrieb help-debb...@gnu.org (GNU bug Tracking System):
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
&
On Dez 04 2022, th3_d0ctor wrote:
> $ echo "*" >b; for i in `cat b`; do echo "$i"; done
> ==> list current working directory instead of printing the wildcard '*'
That's how it is supposed to work, since file name expansion is
performed after all other expansions (just before quote removal).
This
tag 57132 notabug
close 57132
stop
On 11/08/2022 04:05, lingzhiyuan (袁凌志) wrote:
# tail -f log_error.log
tail: unrecognized file system type 0x794c7630 for ‘log_error.log’. please
report this to bug-coreutils@gnu.org. reverting to polling
[cid:image001.jpg@01D8AD72.4C974A50]
This was address
# tail -f log_error.log
tail: unrecognized file system type 0x794c7630 for ‘log_error.log’. please
report this to bug-coreutils@gnu.org. reverting to polling
[cid:image001.jpg@01D8AD72.4C974A50]
On 2/14/22 01:41, Stéphane Archer wrote:
is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want
To format an arbitrary timestamp you want "+%Y-%m-%dT%H:%M:%S.%1NZ",
unless you always want a zero after the period.
Closing the bug report as there's no bug here.
re?
Thank you again and sorry for the bug report, it was late and I was sure to
have found a bug ^^"
Best regards
Stéphane Archer
On Mon, Feb 14, 2022 at 9:17 AM Andreas Schwab
wrote:
> On Feb 13 2022, Stéphane Archer wrote:
>
> > $ date -d "17 april 2022 + 36 week 5pm&quo
On Feb 13 2022, Stéphane Archer wrote:
> $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2022-12-25T17:00:00.0Z
> $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2022-01-01T17:00:00.0Z
> $ date -d "17 april 2022 + 38 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
> 2023-01-0
Hi,
I hope this is the right place to do my bug report.
please see the following shell input-output:
```
$ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
2022-12-25T17:00:00.0Z
$ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z'
20
attached is a bug report... I am compiling LFS 10 on an HP Pavilion G6
Laptop..This happened in chapter 8 after issuing this command...
GNU coreutils 8.32: ./tests/test-suite.log
# TOTAL: 32
ps
>
> etc...
>
> much more attachments to be forwarded now transferred to s9
>
> after factory reset restore
>
> 0433942419
> Hayley Michele
> 30 Louise avenue baulkham hills
> 2153
Sorry - is that a bug report?
You reached the GNU coreutils mailing list, but
On 6/17/20 7:22 AM, Jacek Wielemborek wrote:
Hi!
First of all, thanks for maintaining GNU sort! I use it very often and love
its performance.
Today I spent some time debugging and realized that my bug was caused by a
wrong GNU invocation ("sort -k1,1 -t," instead of "sort -t, -k1,1"). Could
sor
Hi!
First of all, thanks for maintaining GNU sort! I use it very often and love
its performance.
Today I spent some time debugging and realized that my bug was caused by a
wrong GNU invocation ("sort -k1,1 -t," instead of "sort -t, -k1,1"). Could
sort warn when -t is effectively a no-op because i
unrecognized file system type 0x794c7630 for ??error.log??. please report this
to bug-coreutils@gnu.org. reverting to polling
On 03/03/2020 06:15, Scott Baden wrote:
As request in the output for running "make check"
These two issues on macOS will be fixed in the impending release (v8.32)
Specifically they were addressed by:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.31-93-gde73a867c
thanks,
Pád
As request in the output for running "make check"
Attached
Scott Baden
test-suite.log.gz
Description: application/gzip
On 10/28/19 12:34 AM, zhangzhi...@mail.iap.ac.cn wrote:
~>date -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’
Presumably your TZ setting is Asia/Shanghai, as I see the symptoms as
follows:
$ TZ=Asia/Shanghai date -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’
Thi
Mr. maintainers:
Hello! I am very glad to write this email to report my problem.
When I am running commond on my server：
~>date -d "1940-06-01" +"%Y-%m-%d"
date: invalid date ‘1940-06-01’
but the other commond works right：
sense3:~>date -d '1939-06-01' +"%Y-%m-%d"
1939-06-01
se
tag 35636 notabug
thanks
On 5/8/19 3:35 AM, Michele Liberi wrote:
> I verified the following bug is there in:
>
>- sort (GNU coreutils) 8.21
>- sort (GNU coreutils) 8.22
>- sort (GNU coreutils) 8.23
>
> *Input file:*
> # cat sort.in
> 1|a|x
> 2|b|x
> 3|aa|x
> 4|bb|x
> 5|c|x
>
>
> *
I verified the following bug is there in:
- sort (GNU coreutils) 8.21
- sort (GNU coreutils) 8.22
- sort (GNU coreutils) 8.23
*Input file:*
# cat sort.in
1|a|x
2|b|x
3|aa|x
4|bb|x
5|c|x
*shell command and output:*
# sort -t'|' -k2
Dear coreutils authors:
Hi! I'm writing this to report a bug for `cp`. Actually I'm not sure if it
is a bug, but it did something weird on my computer. Command `cp` creates
hardlinks on the second call with `-u`.
The strange behavior was encountered when I tried to copy my files, in
whic
Dear coreutils authors:
Hi! I'm writing this to report a bug for `cp`. Actually I'm not sure if it
is a bug, but it did something weird on my computer.
The strange behavior was encountered when I tried to copy my files, in
which there were a few hardlinks, into a FAT32 partition. At the f
tags 33288 notabug
close 33288
stop
Hello,
On 2018-11-06 6:26 a.m., Adam Solymos wrote:
I have encountered an issue in tail command when running it in a Debian based
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56
UTC 2018 x86_64 GNU/Linux) in a Docker containe
Hi,
I have encountered an issue in tail command when running it in a Debian based
Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56
UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS.
Error message:
tail: unrecognized file system type 0xfe534d
tags 29807 notabug
close 29807
stop
(triaging old bugs)
On 2017-12-21 9:45 p.m., Martin Schwenke wrote:
After reading the documentation again, I realise that it is actually
complete (i.e. no arguments implies --tmpdir).
Given the above, I'm closing this bug.
[...] A separate discussion of T
tags 27640 fixed
close 27640
stop
(triaging old bugs)
On 2017-07-10 1:08 p.m., Paul Eggert wrote:
Looking at that test's source code, the test was clearly incorrect for
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user
names and user IDs. I fixed that in Gnulib by install
tags 27531 moreinfo
close 27531
stop
(triaging old bugs)
On 2017-07-10 10:51 a.m., Pádraig Brady wrote:
On 29/06/17 06:32, Bernardo Lopes Almeida de Oliveira wrote:
Please find attached the test-suite.log.
The seq failure though is due to your system not behaving like:
$ src/seq inf inf
tags 23268 notabug
close 23268
(triaging old bugs)
On 2016-04-11 11:56 a.m., Assaf Gordon wrote:
On 04/11/2016 12:43 PM, 126 wrote:
Every other input is working well,but when my input contain several
lines of "src/table/checkpoint/checkPointInfo5000.lua". The result of
(sort -u) contain two
On 04/22/2018 04:54 AM, Travis Sperry wrote:
> tail: unrecognized file system type 0x794c7630 for '/tmp/cloud_sql_proxy.log’
>
> Travis Sperry
Please update. Your version of coreutils is more than 2 years old.
Support for this file system type has been added in later versions
of coreutils (8.25
tail: unrecognized file system type 0x794c7630 for '/tmp/cloud_sql_proxy.log’
Travis Sperry
travis.sper...@gmail.com
until now, no one responded to my patch proposal neither encorporated
it as I see.
why not?
kalle
Weitergeleitete Nachricht
Betreff: Fwd: Re: bug#29069: info coreutils file permissions:
improvements/bug-report
Datum: Wed, 31 Jan 2018 00:55:31 +0100
Von: kalle
An: bug
unarchive 22151
forcemerge 22151 30482
stop
On 02/16/2018 03:12 AM, Mail.sbo.tech wrote:
Tail: unrecognized file system type 0x794c7630 for ‘/var/log/mail...
Thanks, this is already fixed in coreutils >= 8.25 ... and we're now
at 8.29. See also:
https://www.gnu.org/software/coreutils/files
Tail: unrecognized file system type 0x794c7630 for ‘/var/log/mail...
Sent from my iPhone
I have a patch for chapter 27.3, coreutils texinfo-document.
greetings,
kalle
From b250dcdaba02083a0174d9157c655f0dbb586ef6 Mon Sep 17 00:00:00 2001
From: kalle
Date: Wed, 3 Jan 2018 20:56:07 +0100
Subject: [PATCH] changed presentation in 'File permissions' in 'numeric modes'
I described the nu
Am 16.12.2017 um 22:14 schrieb Assaf Gordon:
> Hello,
>
> On 2017-12-16 01:52 PM, kalle wrote:
>> did you plan to respond my mail?
>
> Please remember GNU coreutils is maintained by volunteers.
> We aim for best effort in incorporating improvement suggestions
> from contributors, but there is n
After reading the documentation again, I realise that it is actually
complete (i.e. no arguments implies --tmpdir).
I would, however, regard the documentation to be structured in a way
that makes it hard to find the information about TMPDIR. That is,
searching for TMPDIR doesn't find the answer.
>> There are many good tutorials and guides available in books and online,
>> e.g. https://wiki.debian.org/Permissions .
>It by the way has a wrong description about unsetting special mode bits
> by doing e.g. `chmod '0755'' (see at "Case 4"), which I will correct as
> soon as possible -> more us
hi,
the parts concerning 27.3 (numeric modes) have been put into a different
e-mail by me.
>On 2017-10-30 02:38 PM, kalle wrote:
>> here some improvement proposals/bug report on info coreutils file
permissions:
>>
>> -in my opinion it would be good to explain the general
tags 29164 notabug
thanks
On Mon, Nov 6, 2017 at 12:21 AM, Thomas Deutschmann wrote:
> please ignore this bug report. This is caused by Gentoo's sandbox in
> portage and no problem in coreutils. Sorry for wasting your time :/
Closing and marking as notabug
Hi,
please ignore this bug report. This is caused by Gentoo's sandbox in
portage and no problem in coreutils. Sorry for wasting your time :/
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
tag 29069 notabug
stop
Hello,
On 2017-10-30 02:38 PM, kalle wrote:
here some improvement proposals/bug report on info coreutils file
permissions:
-in my opinion it would be good to explain the general idea bihind
the file permissions a bit more. what the issues are etc. Elese one
doesn&#
hello,
here some improvement proposals/bug report on info coreutils file
permissions:
-in my opinion it would be good to explain the general idea bihind the
file permissions a bit more. what the issues are etc. Elese one doesn't
really understand, what all the detailed fuss is about.
-w
merge 28929 28970 29022
tag 28929 notabug
thanks
On Sat, Oct 21, 2017 at 02:47:03PM -0400, Mohammad Edghaim wrote:
[...]
> "unrecognized file system type 0x794c7630 for 'xyz.log'. please report this
> to bug-coreutils@gnu.org. reverting to polling"
[...]
On Tue, Oct 24, 2017 at 09:33:56AM -0700, B
Hello,
I got the following message trying to tail a file:
"unrecognized file system type 0x794c7630 for 'xyz.log'. please report this
to bug-coreutils@gnu.org. reverting to polling"
The debug message said please!
Specs:
Windows 7, running VirtualBox VM with an arch linux install, running kernel
[ please don't top-post on technical lists]
On 10/11/2017 04:09 AM, cheng...@zhongan.com wrote:
> On 2017-10-10 20:36, Bernhard Voelker wrote:
>> This is an 'overlayfs' file system - this issue is already fixed since
>> coreutils-8.25
>> (and now we're at 8.28).
>
> It's the latest version, but
On 10/10/2017 05:15 AM, cheng...@zhongan.com wrote:
> [root@HZD-T-QA-TEST-31 logs]# tail -fn 200
> gwhttp-ss_regular_app_gatewayhttp_it_info.log | grep '32d192102a90'
> tail: unrecognized file system type 0x794c7630 for
> ‘gwhttp-ss_regular_app_gatewayhttp_it_info.log’. please report this to
> b
[root@HZD-T-QA-TEST-31 logs]# tail -fn 200
gwhttp-ss_regular_app_gatewayhttp_it_info.log | grep '32d192102a90'
tail: unrecognized file system type 0x794c7630 for
‘gwhttp-ss_regular_app_gatewayhttp_it_info.log’. please report this to
bug-coreutils@gnu.org. reverting to polling
Looking at that test's source code, the test was clearly incorrect for
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user
names and user IDs. I fixed that in Gnulib by installing the attached
patch. Wolfgang, could you please try this on your Linux from Scratch
system? You
Regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27640 :
Hello Wolfgang,
What type of system is this? You are saying "Linux From Scratch version 8.0".
What type of libc is it using? There are several competing ones [1].
> > FAIL: test-getlogin
> > ===
> >
> > test-getlogi
On 10/07/17 00:46, Wolfgang F. Muthmann wrote:
> FAIL: test-getlogin
> ===
>
> test-getlogin.c:92: assertion 'strcmp (pwd->pw_name, buf) == 0' failed
> FAIL test-getlogin (exit status: 134)
Forwarding to gnulib
thanks,
Pádraig
On 29/06/17 06:32, Bernardo Lopes Almeida de Oliveira wrote:
> Dear all,
>
> Please find attached the test-suite.log.
The date false failure is already fixed I think.
The seq failure though is due to your system not behaving like:
$ src/seq inf inf | head -n2
inf
inf
What architecture an
Hi, I just encountered the following report during generation of Linux
>From Scratch version 8.0 :
doing: "make RUN_EXPENSIVE_TESTS=yes check"
Testsu
Thanks for the info — this is in the Windows 10 Tools for Linux and the version
was current available stream ver 1607. I will try it in the Creator’s Preview
builds on the Insider Fast Track and, if it is still a problem there, I will
report it to Microsoft.
Brinkley Harrell
jbharr...@fusemeiste
unarchive 23273
forcemerge 23273 25806
close 25806
stop
On 19/02/17 14:47, jbharr...@fusemeister.com wrote:
> jharrell@PECOS:~/backup-info$ tail -f
> backup-2017-02-19_16\:41\:26_STD.txt
> total size is 49,485,587 speedup is 21,075.63
> sending incremental file list
> Shared/
> sent 59 bytes re
jharrell@PECOS:~/backup-info$ tail -f
backup-2017-02-19_16\:41\:26_STD.txt
total size is 49,485,587 speedup is 21,075.63
sending incremental file list
Shared/
sent 59 bytes received 20 bytes 158.00 bytes/sec
total size is 0 speedup is 0.00
sending incremental file list
CentOS-65-x64/
CentOS-65
unarchive 23273
forcemerge 23273 25516
close 25516
stop
On 24/01/17 07:44, Franklin wrote:
> I was initiating a "tail -f" on a log file of a hamradio digital app, WSJT-X .
>
>
> --
>
> tail: unrecognized file system type 0x53464846 for 'wsjtx.log'. please report
> this to b
I was initiating a "tail -f" on a log file of a hamradio digital app, WSJT-X .
--
tail: unrecognized file system type 0x53464846 for 'wsjtx.log'. please report
this to bug-coreutils@gnu.org. reverting to polling
--
Pass along a link to the bug tracker
(adding debbugs mailing list)
Hello,
On 04/11/2016 12:43 PM, 126 wrote:
Thank you for your reply.
I'm sorry for not describe my problem clearly.
Every other input is working well,but when my input contain several lines of
"src/table/checkpoint/checkPointInfo5000.lua". The result of (sort -u) c
tag 23268 notabug
close 23268
thanks
Hello,
On 04/11/2016 06:49 AM, 126 wrote:
hello, Gentleman
when I use sort and uniq, and input like this below, I got wrong output:
[...]
"|sort -u
[...]
no result when I use `uniq -u`
This is due to wrong usage of 'uniq -u'.
The meaning of '-u' in 'u
hello, Gentleman
when I use sort and uniq, and input like this below, I got wrong output:
$ echo "src/scenelayer/actSceneTipLayer.lua
> src/table/checkpoint/checkPointInfo5000.lua
> src/table/checkpoint/checkPointInfo5000.lua
> src/table/fightscenecheckpoint.lua
> src/scenelayer/actSceneTipLayer.
forcemerge 23143 23176
close 23176
stop
On 01/04/16 08:55, Bernhard Voelker wrote:
Thanks for the report, but I'm afraid the PNGs attached to [0]
are not readable:
The image "..." cannot be displayed because it contains errors.
[0] http://bugs.gnu.org/23176
stored pngs are mangled for me
On 03/31/2016 11:51 PM, Eric Blake wrote:
[moderator note - resending with large .pngs stripped so as not to
overwhelm the list server or recipients; the original bug can be viewed
online at bugs.gnu.org/23176]
Forwarded Message
To: 23...@debbugs.gnu.org
Date: Thu, 31 Mar 2016
[moderator note - resending with large .pngs stripped so as not to
overwhelm the list server or recipients; the original bug can be viewed
online at bugs.gnu.org/23176]
Forwarded Message
To: 23...@debbugs.gnu.org
Date: Thu, 31 Mar 2016 20:55:58 +0200
Message-ID:
From: Hamed OUA
forcemerge 22393 22151
close 22151
stop
On 17/01/16 15:37, Chanan Berler wrote:
> Hello,
>
>
>
> While running WSO2 identity server example inside docker container – I got
> this error message asking me to report the bug.
>
> tail: unrecognized file system type 0x794c7630
The fix will be in
Hello,
While running WSO2 identity server example inside docker container - I got this
error message asking me to report the bug.
So here is the message:
tail: unrecognized file system type 0x794c7630 for 'manager.2016-01-17.log'.
please report this to bug-coreutils@gnu.org. reverting to pollin
Thanks for your elaborate response.
I'm just a beginner with GNU/Linux. I know my terminal code is more
like a patch work and doesn't look that professional yet.
I shortened valbug.txt only to the lines around the (apparent) bugs
with Gedit and looked at the edited file in a hexviewer. Th
On 09/26/2014 07:24 AM, Sorawit Khurnyotrak wrote:
> FAIL: test-getlogin
> ===
> test-getlogin.c:69: assertion 'strcmp (buf, name) == 0' failed
Thanks for the report.
I'm fairly sure that has been fixed up in coreutils-8.23
the recent changes in that gnulib test, specifically:
htt
Dear Sir,
While i compile coreutils-8.22 with LFS i get this error ,
Please correct me.
Best regards,
error.log
Description: Binary data
test-suite.log
Description: Binary data
Yes, it is exactly same as bug#17838. Is -lsh makes me have a misunderstanding
that this file has a size of 4.0K blocks (4000*1024B)
.
Thanks.
发自Gemfield 的 iPhone
> 在 2014年9月19日，上午8:41，Pádraig Brady 写道：
>
> unmerge 17553 18503
> forcemerge 17838 18503
> stop
>
>> On 09/19/2014 01:05 AM, Pádr
On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
gemfield wrote:
4 * 1K blocks = 4.0K blocks.
^^ -> bytes
I think the ambiguity is that there is no unit output.
With the human output options, bytes are the implicit unit rather than blocks.
Those darn trees! Can't
unmerge 17553 18503
forcemerge 17838 18503
stop
On 09/19/2014 01:05 AM, Pádraig Brady wrote:
> unarchive 17553
> forcemerge 17553 18503
> stop
>
> On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
>> gemfield wrote:
>>>Hi,
>>>I am running ls -lsh on kubuntu 14.04, here is the output:
>>>g
unarchive 17553
forcemerge 17553 18503
stop
On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
> gemfield wrote:
>>Hi,
>>I am running ls -lsh on kubuntu 14.04, here is the output:
>>gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
>>4 -rw-rw-r-- 1 gemfield gemfield9 9 18 23:12 test
>>
gemfield wrote:
Hi,
I am running ls -lsh on kubuntu 14.04, here is the output:
gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
4 -rw-rw-r-- 1 gemfield gemfield9 9 18 23:12 test
gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
4.0K -rw-rw-r-- 1 gemfield gemfield9 9 18 23:12 test
Hi,
I am running ls -lsh on kubuntu 14.04, here is the output:
gemfield@gemfield-ThinkPad-Edge:~$ ls -ls
4 -rw-rw-r-- 1 gemfield gemfield9 9 18 23:12 test
gemfield@gemfield-ThinkPad-Edge:~$ ls -lsh
4.0K -rw-rw-r-- 1 gemfield gemfield9 9 18 23:12 test
the "4" colored b
On 08/18/2014 09:57 AM, Pádraig Brady wrote:
> On 08/18/2014 09:55 AM, NTENTOS STAVROS wrote:
>>
>> Hello developers,
>>
>> Recently, using the sort utility I run into an omission. While I cannot
>> disclose the file in question, I will try to explain the issue:
>> On a Windows-created file (line
tag 18291 notabug
thanks
On 08/18/2014 02:55 AM, NTENTOS STAVROS wrote:
>
> Hello developers,
>
> Recently, using the sort utility I run into an omission. While I cannot
> disclose the file in question, I will try to explain the issue:
> On a Windows-created file (line ending: \r\n) I tried to p
On 08/18/2014 09:55 AM, NTENTOS STAVROS wrote:
>
> Hello developers,
>
> Recently, using the sort utility I run into an omission. While I cannot
> disclose the file in question, I will try to explain the issue:
> On a Windows-created file (line ending: \r\n) I tried to perform a sorting,
> whic
Hello developers,
Recently, using the sort utility I run into an omission. While I
cannot disclose the file in question, I will try to explain the issue:
On a Windows-created file (line ending: \r\n) I tried to perform a
sorting, which happened to sort the last entry somewhere above. The
l
Dear sirs:
This bugs is causing errors since many years ago (at least twelve (!)
[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139861]), and let's face
it, if we don't change the point of view it will never get solved. Meanwhile,
the effects of this bug will keep on damaging the works of L
On 01/04/2014 06:01 AM, Pádraig Brady wrote:
> On 01/04/2014 03:04 AM, Pieter van Voorst Vader wrote:
>> Hi bug-coreutils,
>> got this bug in tail for a hfsplus filesystem on ubuntu 13.10
>>
>> tail: unrecognized file system type 0x482b for ‘serviio.log’. please
>> report this to bug-coreutils
s 2 mails)
> __
>
>Caracas, Sunday 26th, 2014
>Ref: Bug report for 'head' (and 'wc' et. al.)
>Dear friends:
> Please find attached the text file 'head-tst.txt'
>
> As you easily can see, the following command fails and do not print
&g
On 01/04/2014 03:04 AM, Pieter van Voorst Vader wrote:
> Hi bug-coreutils,
> got this bug in tail for a hfsplus filesystem on ubuntu 13.10
>
> tail: unrecognized file system type 0x482b for ‘serviio.log’. please
> report this to bug-coreutils@gnu.org. reverting to polling
Cool thanks, we'll
Hi bug-coreutils,
got this bug in tail for a hfsplus filesystem on ubuntu 13.10
tail: unrecognized file system type 0x482b for ‘serviio.log’. please report
this to bug-coreutils@gnu.org. reverting to polling
with kind regards,
Pieter
tag 15407 notabug
thanks
On 09/18/2013 07:07 AM, João Marques wrote:
> Hi good afternoon
>
> Yesterday i was reading the manual (man date) of the date command and I
> think that the option + and ' isn't refer on it
>
> so i was trying to make this command on a script:
>
> $(date +'%Y-%m-%d '%H
Hi good afternoon
Yesterday i was reading the manual (man date) of the date command and I
think that the option + and ' isn't refer on it
so i was trying to make this command on a script:
$(date +'%Y-%m-%d '%H:%M:%S')
maybe I'm wrong but if not, it was nice to include this information an some
ustaining Engineering (formerly DDR)
Server Technologies, Oracle e-mail: mark.jae...@oracle.com
On Fri, 22 Mar 2013, Eric Blake wrote:
Date: Fri, 22 Mar 2013 10:03:47 -0600
From: Eric Blake
To: Pádraig Brady
Cc: mark.jae...@oracle.com, Marc Grondin ,
13947-d...@debbugs.gnu.org
Subject:
On 03/27/2013 12:39 PM, Mark JAEGER wrote:
> Hello Eric,
>
> The terms "single-byte character" and "single-byte
> printable character" do not sound precise to me.
They are precise - they are characters in the encoding determined by the
current setting of LC_CTYPE.
>
> A byte is just a byte. It
On 03/22/2013 04:03 PM, Eric Blake wrote:
> On 03/22/2013 09:45 AM, Pádraig Brady wrote:
>> @table @samp
>> @item a
>> named character, ignoring high-order bit
>> @item c
>> -ASCII character or backslash escape,
>> +printable single byte character or backslash escape,
>
> Hmm, we output octal
On 03/22/2013 09:45 AM, Pádraig Brady wrote:
> Hopefully the attached clarifies things.
> * src/od.c (usage): Mention any printable character is output,
> Not just ASCII.
> * doc/coreutils.texi (od invocation): Further clarify that only
> single byte characters are output (due to the alignment req
On 03/13/2013 09:53 PM, Pádraig Brady wrote:
> On 03/13/2013 09:34 PM, Eric Blake wrote:
>> In reality, that should state something like:
>
>> Output as characters in the current locale, using octal sequences
>> or backslash escapes for all non-graphic bytes.
>
> Note we output spaces, so I'
On 03/13/2013 09:34 PM, Eric Blake wrote:
> On 03/13/2013 02:16 PM, Marc Grondin wrote:
>> Good Afternoon,
>
> Hello, and thanks for the report.
>
>>
>> My client was attempting to run the command : od -c on this xml file (sample
>> only)
>>
On 03/13/2013 02:16 PM, Marc Grondin wrote:
> Good Afternoon,
Hello, and thanks for the report.
>
> My client was attempting to run the command : od -c on this xml file (sample
> only)
> --
>
>
>丸
Here, you are
Good Afternoon,
My client was attempting to run the command : od -c on this xml file (sample
only)
--
丸
丸
𠄌
?
?
?丸
??丸
s
Michael
--
From: "Paul Eggert"
Sent: Wednesday, October 17, 2012 11:14 PM
To: "Michael"
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug report!
On 10/17/2012 12:19 AM, Michael wrote:
# sort -n file1 > file3
# sort -n file2 > file4
# join f
ssed
> in the manual.
Since this seems to have been resolved satisfactorily I have closed
the bug report. If you have any further information please feel free
to respond as I have done here and it will be delivered to all of the
interested parties.
Bob
On 10/17/2012 12:19 AM, Michael wrote:
> # sort -n file1 > file3
> # sort -n file2 > file4
>
> # join file3 file4
That won't work. You have to join with the same
sorting order that you sorted with. This is discussed
in the manual.
on '-n', the result after joining was correct.
Michael
--
From: "Paul Eggert"
Sent: Wednesday, October 17, 2012 12:10 AM
To: "Michael"
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug rep
Sounds like a locale problem. What does the "locale"
command say? How exactly are you invoking 'sort' and
'join'? What do the input and output lines look like?
1 - 100 of 283 matches
Mail list logo
