Pádraig Brady wrote:
> Moritz Poldrack wrote:
> > Pádraig Brady wrote:
> > > Both fold and fmt have overlapping functionality.
> > > fold is more lower level, using less context,
> > > and is operating as expected in this case.
> >
> > Thank you for your help. That's exactly what I wanted :) There
David Chmelik wrote:
> I noticed two types for weeks in year: 1 to 53, 0 to 53, numbering
> 54 weeks, but there can't be 54, right?
> Only two options exist to number weekdays, when should be
> more/user-configurable.
The %Y and %U or %W options work in combination. Use %U for
Karl Berry wrote:
> 'fdatasync'
> Synchronize output data just before finishing. This forces a
> physical write of output data.
>
> 'fsync'
> Synchronize output data and metadata just before finishing.
> This forces a physical write of output data
Pádraig Brady wrote:
> I just noticed some de facto treatment of the NO_COLOR env var.
> https://no-color.org/
I happened to run across this site myself a few weeks ago. When I saw
it I had this immediate feeling of community. Here was someone else
who also felt the oppression of endless
Fariya F wrote:
> Yes it is an embedded system. The package we have used is coreutils 8.25
> and not 1.35. Very sorry for the confusion.
Ah! No worries. :-)
Then I will ask if my assumption about /dev/mmcblk2 being an SD card
is incorrect? Is it actually soldered on flash NAND? In which case
Rob Landley wrote:
> Fariya F wrote:
> > The version of df command is 1.85.
A current version of Coreutils df by most distros would be 8.x and the
upstream stable version is version 9. This leads me to believe that
the df you are using is not from Coreutils but from somewhere else.
But not
Fariya F wrote:
> My eMMC device has a partition which reports the below output from df -h
> command:
>
> Filesystem Size Used Avail Use% Mounted on
> /dev/mmcblk2p316Z 16Z 84M 100% /data
Since the df command is simply reporting back on what the Linux kernel
reports, and the kernel
Vladimir D. Seleznev wrote:
> Expected behavior is:
> # id user1
> uid=1027(user1) gid=1027(user1) groups=1027(user1)
> # id user2
> uid=1027(user1) gid=1027(user1) groups=1027(user1),1028(somegroup)
I just tried a test on both FreeBSD and NetBSD and both FreeBSD and
Darryl Okahata wrote:
> Bob Proulx wrote:
> Inconsistencies like this are why I wish it had never been implemented.
> Best to avoid the syntax completely.
>
> Thanks. I'll avoid date and use either python or ruby to get this info.
To be clear what I meant was tha
zendas wrote:
> Hello, I need to get Chinese characters from the string. I googled a
> lot of documents, it seems that the -c parameter of cut should be
> able to meet my needs, but I even directly execute the instructions
> on the web page, and the result is different from the
> demonstration. I
Darryl Okahata via GNU coreutils Bug Reports wrote:
> From coreutils 9.0 (note the difference between the "second" and "third"
> saturdays):
...
> $ src/date --debug -d "second saturday"
> date: parsed relative part: +1 seconds
Caution! The date utility can't parse second due to second being a
21625039 wrote:
> [root@fedora ~]# ll test.txt
> -rwsr-x---. 1 root root 0 Dec 13 21:13 test.txt
>
> [root@fedora ~]# chown root:root test.txt
> [root@fedora ~]# ll test.txt
> -rwxr-x---. 1 root root 0 Dec 13 21:13 test.txt
That is a feature of the Linux kernel, OpenBSD kernel, and NetBSD
Bob Proulx wrote:
> Paul Eggert wrote:
> > Robert Swinford wrote:
> > > BTW, zsh globbing doesn’t exhibit this behavior! It seems it is only a
> > > problem in bash.
> >
> > In that case, the bug (whatever it is) wouldn't be a coreutils bug.
>
> I
Paul Eggert wrote:
> Bob Proulx wrote:
> > mv calls it SOURCE and DEST. cp calls it SOURCE and DEST. Perhaps ln
> > should also call it SOURCE and DEST too for consistency?
>
> That's what ln did long ago, but that wording was deemed too confusing.
> Here's where we cha
Andreas Schwab wrote:
> Bob Proulx wrote:
> > The more I think about it the more I think it should say CONTENT
> > rather than either TARGET or SOURCE. Because it is actually setting
> > the content of the symbolic link.
>
> A hard link doesn't have content.
But we
Paul Eggert wrote:
> Robert Swinford wrote:
> > This seems like a bug:
> > https://twitter.com/nixcraft/status/1465599844299411458
>
> I don't see a coreutils bug there: rm operated as specified.
Agreed. It's not an rm bug. It's definitely unfortunate. It's
similarly unfortunate to riding a
Bob Proulx wrote:
> With symbolic links the symlink contains a string. The string could
> be pretty much anything.
The more I think about it the more I think it should say CONTENT
rather than either TARGET or SOURCE. Because it is actually setting
the content of the symbolic link. The
Ulf Zibis wrote:
> Currently we have:
> List-Post: GNU coreutils Bug Reports
>
> When using "reply list" to answer to a comment of bug 12345 in a email client
> such as Thunderbird, my reply is sent to bug-coreutils@gnu.org, but it should
> be sent to 12...@debbugs.gnu.org
>
> So I think, we
Chris Elvidge wrote:
> Paul Eggert wrote:
> > Ulf Zibis wrote:
> > > I think, for beginners it would be less confusing, if the most
> > > simple form would be the first.
> >
> > Unfortunately the simple form "ln TARGET" is quite rarely used, so
> > putting it first is likely to confuse beginners
Warren Parad wrote:
> except mv(1) and cp(1) are both "FROM" and then "TO", but ln is backwards
> from thi, it is "TO" then "FROM", the least the command could do is put
> these in the correct order.
But that is not correct. The order for ln is the same as for cp and
mv in that the target
Sworddragon wrote:
> On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_64 and GNU Coreutils
> 8.32 I wanted to overwrite my USB Thumb Drive a few times with random data
> via "dd if=/dev/random of=/dev/sdb bs=1M conv=fsync". While it usually
> takes ~2+ minutes to perform this action dd returned
Florent Flament wrote:
> Bob Proulx writes:
> >> In which case, thoroughly documenting the edge cases of the 'echo'
> >> command and inviting programmers to use 'printf' instead on its
> >> manpage (I know 'printf' is mentioned on the coreutils info page,
>
Florent Flament wrote:
> Bob Proulx wrote:
> However, I believe that the use of "shall not" makes the POSIX echo
> definition ambiguous:
>
> The echo utility shall not recognize the "--" argument in the
> manner specified by Guideline 10 of XBD Utili
tolugboji via GNU coreutils General Discussion wrote:
> If "sort" did support multiple delimiters, I could numerically sort the
> following set of filenames
> using the second field.
>
> schimmel-04.png
> schimmel-05.png
> schimmel-06.png
> schimmel-07.png
> schimmel-08.png
> schimmel-09.png
>
Florent Flament wrote:
> Out of curiosity, would it possible to have the `echo` command output
> the string "-n" ?
>
> ```
> $ POSIXLY_CORRECT=1 /bin/echo -n
> ```
But the standards do actually mention -n. The behavior you see with
POSIXLY_CORRECT=1 is conforming behavior.
Lars Nooden wrote:
> On March 29, 2021, if a relative date of '-1 month' is passed to 'date',
> then the output shows March instead of February.
The date manual includes this section on relative months.
The fuzz in units can cause problems with relative items. For
example,
Peng Yu wrote:
> By discouraging people from using it for a long period (say 10 years),
> its support can be dropped eventually which will reduce future
> maintenance costs of this duplicate code.
Removing it would needlessly break old scripts. It used to be the
only way to create named pipes.
tag 47353 + notabug
close 47353
thanks
Dan Jacobson wrote:
> Or (info "(coreutils) Backup options") should "admit" that "Numbered
> backups need to be trimmed occasionally by the user, lest the fill up
> the disk."
If the user has asked for them then any decision of the disposition of
them is up
✓ Paul Courbis de Bridiers de Villemor wrote:
> Actually I’d prefer to have reliable tools to convert csv to tsv and tsv to
> csv, replacing tabs and newlines by \t \n and to be able to use all
> standard tools
I would find this approach the better direction, more desirable, and
more flexible
Peng Yu wrote:
> It seems that both `mkfifo` and `mknod ... p` can create a fifo. What
> is the difference between them? Thanks.
The mknod utility existed "for a decade" in Unix (don't quote me on
that vague time statement) before mkfifo existed. The mknod utility
existed in Unix v7 as a thin
Erik Auerswald wrote:
> Grigoriy Sokolik wrote:
> > I've rechecked:
>
> I cannot reproduce the problem, the certificate is trusted by my system:
>
> # via IPv4
> $ gnutls-cli --verbose translationproject.org 'Connecting|Status'
> Connecting to '80.69.83.146:443'...
> - Status:
Is this problem still a problem? Perhaps it has been fixed in the
time this has been under discussion? Because it looks okay to me.
Grigoriy Sokolik wrote:
>$ curl -v https://translationproject.org/latest/coreutils/ -o /dev/null
...
>* Connected to translationproject.org (80.69.83.146)
close 45182
tag 45182 + notabug
thanks
Vasanth M.Vasanth wrote:
> When I create a temp file from root users using mktemp command, then it is
> not able to access other users. If the same do in other users then the
> group and user came respectively.
I see no difference in behavior of GNU
zed991 wrote:
> On linux, I can use date +%s --date "31 Dec 1969"
> The result is -9
> A negative number
Which is correct for dates before the 0 time:
Thu, 01 Jan 1970 00:00:00 +
https://en.wikipedia.org/wiki/Unix_time
> But when I try it on Windows (using GNUWin32) it gives
Martin Fido wrote:
> I have tzdata version 2020a:
>
> $ apt-cache policy tzdata
> tzdata:
> Installed: 2020a-0ubuntu0.16.04
> Candidate: 2020a-0ubuntu0.16.04
> ...
>
> $ zdump -v Australia/Sydney | grep 2020
> Australia/Sydney Sat Apr 4 15:59:59 2020 UT = Sun
Martin Fido wrote:
> I seem to have found a bug in the date utility, converting from UTC
> to Sydney time. It returns invalid date for what should be perfectly
> valid:
>
> $ TZ='Australia/Sydney' date -d '2020-10-04T02:00:00Z'
> date: invalid date ‘2020-10-04T02:00:00Z’
>
> $
close 43657
thanks
Paul Eggert wrote:
> On 9/27/20 8:58 PM, Amit Rao wrote:
> > There's a limit? My first attempt didn't use a wildcard; i attempted to
> > delete a directory.
>
> 'rm dir' fails because 'rm' by default leaves directories alone.
>
> > My second attempt was rm -rf dir/*
>
> If
Paul Eggert wrote:
> Karl Berry wrote:
> > I was on centos7.
> >
> > (I don't observe your problem on my Fedora 31 box, for example).
> >
> > Maybe there is hope for a future centos, then.
Just another few data points...
I was able to recreate this issue on a CentOS 7 system running in a
tag 43541 + notabug
close 43541
thanks
Nikolay wrote:
> GNU coreutils 8.30
Coreutils version 8.30. Gotcha.
> $ pwd --version
> bash: pwd: --: invalid option
> pwd: usage: pwd [-LP]
But that is not the GNU Coreutils pwd program. That is the shell
builtin pwd. In this case it is bash. And
tags 42440 + notabug
thanks
wrote:
> sometimes,rm can't delete the file.
> but when using rm -rf + file .
> the file can be deleted.
This does not sound like a bug in the rm command. Therefore I am
tagging this as such. If you have follow up information and this
turns out to be an actual
Pádraig Brady wrote:
> jens wrote:
> > It would make shell scripts that use sha256sum much simpler. Currently it
> > is necessary to split the output of sha256sum to obtain the hash, which
> > usually requires an additional command / Unix process.
>
> This is one of those trade-offs.
> I'd be
Vito Caputo wrote:
> Does this already exist?
>
> Was just moving a .tgz into a deep path and realized I hadn't created
> it on that host, and lamented not knowing what convenient flag I could
> toss on the end of the typed command to make `mv` do the mkdir -p
> first for me.
I suggest using the
L A Walsh wrote:
> I allocated a large file of contiguous space (~3.6T), the size of a disk
> image I was going to copy into it with 'dd'. I have the disk image
> 'overwrite' the existing file, in place ...
It's possible that you might want to be rescuing data from a failing
disk or doing other
close 41792
thanks
Since the discussion has moved away from anything GNU Coreutils
related and doesn't seem to be reporting any bugs in any of the
utilities I am going to close the bug ticket. But discussion may
continue here regardless. If we see a dd bug we can re-open the
ticket.
Ricky Tigg
close 41657
thanks
No one else has commented therefore I am closing the bug ticket. But
the discussion may continue here.
Michael Coleman wrote:
> Thanks very much for your prompt reply. Certainly, if this is
> documented behavior, it's not a bug. I would have never thought to
> check the
Hello Michael,
Michael Coleman wrote:
> $ true > \\
> $ md5sum \\
> \d41d8cd98f00b204e9800998ecf8427e \\
> $ md5sum < \\
> d41d8cd98f00b204e9800998ecf8427e -
Thank you for the extremely good example! It's excellent.
> The checksum is not what I would expect, due to the leading
> backslash.
Paul Eggert wrote:
> So I'd prefer having 'df' just do the "right" thing by default, and
> to have an option to override that. The "right" thing should be to
> ignore all these pseudofilesystems that hardly anybody cares about.
+1! Which I thought I would say because often I am a status quo type
Paul Eggert wrote:
> * src/echo.c (main): Don’t assign pointer to bool.
> This is well-defined in C99, but is arguably bad style
> and Oracle Studio 12.6 complains.
...
> + bool posixly_correct = !!getenv ("POSIXLY_CORRECT");
Of course this is fine. But because char *getenv() returns a pointer
Yair Lenga wrote:
> For the first point, I would note that most coreutils goes well beyond
> POSIX. Consider "cp", which has many useful additions beyond the POSIX
> features.
Most of those additions were due to file systems with new features and
therefore cp needed to be able to deal with those
tag 41554 + notabug
close 41554
thanks
Will Rosecrans wrote:
> Based on an inane interview question that was discussed here on Twitter:
> https://twitter.com/QuinnyPig/status/1265286980859908102
It's an interview question. The purpose of this type of question is
never a practical existing
Yuan Cao wrote:
> > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-_0027od-_002dx_0027-command-prints-bytes-in-the-wrong-order_002e
>
> Thanks for pointing me to this documentation.
>
> It just feels strange because the order does not reflect the order of the
> characters in
A little more information.
Pádraig Brady wrote:
> Yuan Cao wrote:
> > I recently came across the following behavior.
> >
> > When using "--traditional x2" or "-x" option, it seems the order of hex
> > code output for the characters is pairwise reversed (if that's the correct
> > way of
Keith Neargarder wrote:
> I am trying to execute a Perl script using nohup but I get the
> error:nohup: cannot run command 'test.pl': Exec format error
Your operating system apparently does not understand #! scripts.
I can see that you are running MS-Windows. Obviously the GNU Project
is
富田黎 wrote:
> I want to know the difference between stty command with "speed" and without
> "speed".
With the "speed" command the stty program prints the speed. Without
it there is no printing of the speed.
The Coreutils stty manual says:
‘speed’
Print the terminal speed.
> When I
taehwan jeoung wrote:
> Can this error message be clarified? The directory already exists, it is
> not a file.
That is incorrect. Directories are files. FIFOs are files. Device
nodes are files. Symlinks are files. Network sockets are files.
They are all files. Therefore it is not incorrect
Jonny Grant wrote:
> Paul Eggert wrote:
> > Jonny Grant wrote:
> > > Is a more accurate strerror considered unreliable?
> > >
> > > Current:
> > > mkdir: cannot create directory ‘test’: File exists
> > >
> > > Proposed:
> > > mkdir: cannot create directory ‘test’: Is a directory
> >
> > I don't
tag 40958 + notabug
close 40958
thanks
GNAT via GNU coreutils Bug Reports wrote:
> I am going to hazard a guess and say this is the expected behaviour,
> but I cannot find anything though goog.
The FAQ gives the recipe to figure these types of problems out.
tag 40904 + notabug
close 40904
thanks
Jim Clark wrote:
> When I list a hard drive "ls -AR > list.txt" and import it into Libreoffice
> Calc, then break the lines using "text-to-columns", I am not able to
> perform a fixed format break so that the filenames are placed in their own
> column.
>
>
Paul Eggert wrote:
> Bob Proulx wrote:
> > By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):
>
> GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant
> to this bug report?
GNU date uses clock_settime() and settimeofday() on my Deb
Paul Eggert wrote:
> Bob Proulx wrote:
> > I tested this in a victim system and if I was very quick I was able to
> > log in and set the time to :10 seconds but no earlier.
>
> Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10
> seconds when
tag 40220 + notabug
close 40220
thanks
shy wrote:
> I use command date -s "1970-01-20 00:00:00" to set date, but it
> failed. there is error message "date: can't set date: Invalid
> argument".
> It's UTC time and no timezone.
This is most likely a limitation of your kernel. I can
Hyunho Cho wrote:
> $ find /usr/bin -type f | wc -l
> 2234
>
> $ find /usr/bin -type f -print0 | du -b --files0-from=- | wc -l
>
Hard links. Files that are hard linked are only counted once by du
since du is summing up the disk usage and hard linked files only use
disk on the first usage.
Bernhard Voelker wrote:
> I had to take out your email address to be able to reply to this issue:
>
> An error occurred while sending mail. The mail server responded:
> Requested action not taken: mailbox unavailable
> invalid DNS MX or A/ resource record.
There is a useful feature of
Antti Savolainen wrote:
> When doing a shortcut to unmount in a specific order, I am unable to
> specify order with angle brackets. For example using 'umount /dev/sda[132]'
> will result in the system unmounting them in numerological order. First 1
> then 2 and finally 3. What I need it to do is
TJ Luoma wrote:
> AHA! Ok, now I understand a little better. I have seen the difference
> between "size" and "size on disk" and did not realize that applied
> here.
>
> I'm still not 100% clear on _why_ two "identical" files would have
> different results for "size on disk" (it _seems_ like those
tag 35685 + notabug
close 35685
thanks
Safdar Iqbal wrote:
> Sir,Provide me to installation procedure of wien2k(14.2) on ubuntu
> (19.04)sir chmod command cannot excite on my workstation core i7sir
> please guide methanks
Hello! You are asking about WIEN2k (http://www.wien2k.at/) and also
The essence of this report appears to be an attack of the form, can we
get the root user to perform an unsafe operation, in this case can we
trick root into dereferencing a symbolic link, such as from ./poc to
/etc, in order to perform a further action through the symlink.
However this is not a
close 35167
thanks
Hello 往事随风,
往事随风 wrote:
> OS centos6.10
> kernel vmlinuz-2.6.32-754.el6.x86_64
> hello!
> grub-install in a new disk /mnt/boot;copy /bin/bash and *.so ; chroot
> /mnt/sysroot is ok!exit and ctrl+d
Sounds like 'chroot' worked correctly in the above sequence.
> use the new
tags 34713 notabug
close 34713
thanks
Hello Christoph,
Christoph Michelbach wrote:
> To reproduce this bug, you need two different file systems. Adapt the
> paths to fit your system.
Thank you for making this bug report. However what you are
experiencing is due to the race condition created by
Erik Auerswald wrote:
> Bob Proulx wrote:
> > However regardless of intentions and design if one really wants to
> > smash it then this is easily scripted. No code modifications are
> > needed.
> >
> >#!/bin/sh
> >chmod -R u+w $1
> >rm
Nicolas Mailhot wrote:
> For their own reasons, the Go maintainers have decided the user Go cache
> will now be read-only.
> https://github.com/golang/go/issues/27161#issuecomment-433098406
Not wise.
> That means cleaning up cache artefacts with rm does not work anymore
>
L A Walsh wrote:
> Bob Proulx wrote:
> > Please provide an example. Something small. Something concrete.
> > Please include the version of rmdir.
>
> The original bug stems from having to use wild cards to delete
> all files in a directory instead of '.', as in being
vampyre...@gmail.com wrote:
> The man page for wc states: "A word is a... sequence of characters delimited
> by white space."
>
> But its concept of white space only seems to include ASCII white
> space. U+00A0 NO-BREAK SPACE, for instance, is not recognized.
Indeed this is because wc and
tag 34447 + notabug
close 34447
thanks
Hello Chris,
Chris Wright wrote:
> I found that if a session's working directory is renamed or moved,
> `pwd` doesn't show the real working directory.
Thank you for your bug report. However I think the shell's built-in
pwd is being confused with the
Chris Kalish wrote:
> Hmmm ... not sure of the distribution, but the help file pointed me at this
> address:
> C:\> cp --version
> cp (GNU coreutils) 5.3.0
I always hate it when I am on your side of things and upstream says
this to me. But here I am on the other side and going to say almost
L A Walsh wrote:
> >> If you want a recursive option why not use 'rm -rf'?
>
> rmdir already provides a recursive delete that can cross
> file system boundaries
Please provide an example. Something small. Something concrete.
Please include the version of rmdir.
Something like:
mkdir testdir
anatoly techtonik wrote:
> Bob Proulx wrote:
> > > Human users have UIDs starting at 1000,
> >
> > That assumption is incorrect. Many systems start users off at 100.
> > Many others start users at 500. There isn't any univerial standard.
> > It is a local s
tags 33943 notabug
close 33943
merge 33942
thanks
This message generated a new bug ticket. I merged it with the
previous bug ticket.
westlake wrote:
> I have omitted that I recently downgraded my coreutils to doublecheck
> behaviour for ls, and noticed immediately the same behaviour was
積丹尼 Dan Jacobson wrote:
> For files with blanks in their names,
> one shouldn't need this workaround:
> $ ls -t | tr \\n \\0 | xargs -0 more > /tmp/z.txt
> Please add a --print0 option. like find(1) has.
I think that adding a --print0 option to 'ls' is not wise because it
would suggest to people
Daniel Böhmer wrote:
> I want to propose a new parameter to the "mv" command which
> helps when working with nested directory structures from the
> structure's root dir as $PWD.
New options require a strong rationale for addition.
> Similar to the "ln" command's "--relative" parameter "mv"
>
fdvwc4+ekdk64wrie5d8rnqd9...@guerrillamail.com wrote:
> Under the section in the FAQ about uname, it refers to ``the Linux
> kernel." Is not the GNU position that Linux should be referred to as
> ``Linux, the kernel' or something similar?
Thank you for asking! It gives us a chance to talk. :-)
Mihir Mehta wrote:
> I thought you might want to fix a broken link (to
> http://stagecraft.theprices.net/nomime.html) that appears on the main
> Coreutils website (https://www.gnu.org/software/coreutils/coreutils.html).
Thank you for you reporting that problem. It's appreciated. We
didn't know
Marc Weber wrote:
> So the question would turn into would it make sense to create a new tool
> which (optionally cleans up) like this:
>
> with-mounts sys,proc,dev -- chroot ...
>
> There might be many use cases.
>
> I think there is interest. But I'm unsure where would be the place to
> put
Garreau, Alexandre wrote:
> Yet that FAQ section seems to be somewhat outdated:
It became outdated when ext3 became popular. Because journaling file
systems zero out the data. Originally I had said rather strongly that
when deleted the files were gone. But then there were many people who
Pádraig Brady wrote:
> Paul Eggert wrote:
> > trap '' PIPE
>
> Generally you don't want to ignore SIGPIPE.
> http://pixelbeat/programming/sigpipe_handling.html
> as then you have to deal with EPIPE from write():
I wanted to add emphasis to this. Ignoring SIGPIPE causes a cascade
of associated
Nellis, Kenneth wrote:
> Still, my -f suggestion would be easier to type,
> but I welcome your alternatives.
Here is the problem. You would like dirname to read a list from a
file. Someone else will want it to read a file list of files listing
files. Another will want to skip one header line.
Pádraig Brady wrote:
> Nellis, Kenneth wrote:
> > E.g., to get a list of directories that contain a specific file:
> >
> > find -name "xyz.dat" | dirname -f -
>
> find -name "xyz.dat" -print0 | xargs -r0 dirname
Also if using GNU find can use GNU find's -printf operand and %h to
print the
Paul Eggert wrote:
> How about the attached (untested) patch instead? It should fix the
> underlying problem, and thus avoid the need for fiddling with compiler
> flags.
> diff --git a/configure.ac b/configure.ac
> index 66c8cbe..3f546e9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@
Eric Blake wrote:
> Bob Proulx wrote:
> > Or is a return 0 already defaulted? It stood out to me that the
> > previous return was unconditional and without an else or a
> > fallthrough this is a change from the previous control flow.
> >
> > -return !(stdbu
Macdonald, Kim - BCCDC wrote:
> Sorry for the confusion - I wanted to add a tab (or even a new line)
> after each file that was concatenated. Actually a new line may be
> better.
>
> For Example:
> Concatenate the files like so:
> >gi|452742846|ref|NZ_CAFD01001.1| Salmonella enterica subsp.,
Pádraig Brady wrote:
> Upon more careful consideration, I'm 50:50
> about adding per line processing to tail.
>...
> Perhaps we could just add the above snippet to the docs?
> The big advantage is that it works everywhere already.
Perhaps simply add a reference to 'multitail' being available? It
Bernhard Voelker wrote:
> I'm not convinced that a new --no-stdout option is warranted:
> why not simply redirect stdout to the last fifo?
>
> cat /dev/zero | head -c500M \
> | (/dev/shm/AAA/coreutils-8.24/src/tee -p \
> $d/fifo1 $d/fifo2 $d/fifo3 > $d/fifo4 ) 2>&1 \
> | > tee
Pádraig Brady wrote:
> Jirka Hladky wrote:
> > => it's almost there expect that it runs forever because of >/dev/null
I am going to suggest this without trying it, always dangerous, but I
have no time for a deep investment. Sorry. What about closing
stdout? Then it would be closed right from
Pádraig Brady wrote:
> Already done in the previous v8.24 release:
Bob Proulx wrote:
> If you ignore SIGPIPE in tee in the above then what will terminate the
> tee process? Since the input is not ever terminated.
http://www.gnu.org/software/coreutils/manual/html_node/tee-invocation
Jirka Hladky wrote:
> I have recently run into an issue that tee will finish as soon as first
> pipe it's writing to is closed. Please consider this example:
>
> $cat /dev/zero | tee >(head -c1 | wc -c ) >(head -c100M | wc -c ) >/dev/null
> 1
> 65536
>
> Second wc command will receive only 64kB
Adam Brenner wrote:
> I have an enhancement requests and patch ready for unlink to support
> multiple arguments. Currently unlink does not accept more than one
> argument to remove a link. I have a patch that adds that
> functionality. For example:
>
> $ unlink link1 link2 link3
Why are you
Pádraig Brady wrote:
> Bob Proulx wrote:
> > Why are you using unlink here instead of rm? I think you are using
> > the wrong tool for the job. Why even care if unlink can take multiple
> > arguments?
>...
> Good info thanks. Yes rm will not unlink() a dir.
Is the use
Pádraig Brady wrote:
> Ngô Huy wrote:
> > > I had problem with mkdir and ls when I used command:
> > >
> > > mkdir "* /" && mkdir "* /etc" && ls.
> > >
> > > It only displayed *.
> >
> > Note as yet unreleased version of ls will use shell quoting
> > to give a less
Flemming Gulager Danielsen wrote:
> I am new here so if this is not the proper use of the maillist then
> I am sorry.
Others answered your output buffering question. Let me address the
mailing list question.
When you send a message to bug-coreutils it opens a bug ticket so that
we can track
Pádraig Brady wrote:
> Christoph Anton Mitterer wrote:
> > Attached is a file, that, when sort -u'ed in my locale, looses lines
> > which are however unique.
> >
> > I've also attached the locale, since it's a custom made one, but the
> > same seem to happen with "standard" locales as well, see
1 - 100 of 1396 matches
Mail list logo
