mktemp: Please add an option which creates a fifo
instead of a file or a directory. "--fifo" seems appropriate,
although the abbreviation "-f" might be confused as a request
for an ordinary file; and "-p" as in "--pipe" is already taken
for "prefix".
--
On 08/23/2010 09:40 AM, Eric Blake wrote:
> On 08/23/2010 09:22 AM, John Reiser wrote:
>> mktemp: Please add an option which creates a fifo
>> [snip]
>
> Thanks for the report. However, I'm inclined to mark this bug as a
> duplicate of 6330, for the reasons al
On 08/23/2010 11:00 AM, Eric Blake wrote:
[snip]
> If we add 'mktemp --fifo', then where do we stop? What about creating a
> uniquely named symlink? Or a new shared memory object?
There are several possible answers to "Where do we stop?".
1) Stop at current code [no changes.]
2) Stop when us
On 08/23/2010 02:22 PM, Paul Eggert wrote:
> On 08/23/2010 01:40 PM, John Reiser wrote:
>> Two independent user requests [one of which
>> includes code!] within a few months show a definite need.
>
> The two requests would have been more convincing if they demonstrated
> a
On 08/24/2010 11:32 AM, Paul Eggert wrote:
[snip]
> Again, once things get this complicated, it doesn't cost any more
> processes to use a temporary directory, with something like this:
>
> dir=$(mktemp -d dir.XX)
> mkfifo $dir/1 $dir/2
> listener1 < $dir/1
> listener2 < $dir/2
> c
> (echo quit 1 | cmd1 3<&0 <&4) 4<&0 |
> (: | cmd2 3<&0 <&4) 4<&0
When adopting this style, then remember to consider the possibility of
closing the "extra" file descritpor (fd 4 here) to reduce the number
of open files. If there are no 'trap', then also remember to consider
the pos
On 08/24/2010 11:32 AM, Paul Eggert wrote:
> dir=$(mktemp -d dir.XX)
> mkfifo $dir/1 $dir/2
> listener1 < $dir/1
> listener2 < $dir/2
> cmd1 2> $dir/1 | cmd2 2> $dir/2
> Better yet, do not use named fifos, since pipes suffice:
>
> (cmd1 2>&1 >&3 | listener1) 3>&1 |
> (cmd2 2>&1
On 09/27/2011 12:33 PM, Paul Eggert wrote:
> This happened with coreutils 8.13 on Fedora 14 x86-64
> (coreutils compiled with GCC 4.6.1). I interrupted
> 'dd' with control-C, but it didn't respond right away;
> instead, it churned away and created the entire output file,
> issuing a bogus diagnost
> Is there any way to compare the non-padding parts of long doubles?
> There ought to be *some* way to get the fractional part of a NaN, no?
frexp() [man 3 frexp] would be the right idea,
except that it fails explicitly for NaN.
--
> I found this in the man page of /dev/urandom on Solaris: "The limitation per
> read for /dev/random is 1040 bytes. The limit for /dev/urandom is (128 *
> 1040 = 133120)." That seems to be the reason but I think dd should handle
> that and check the return value of the read() system call and make
On 12/10/2012 07:21 AM, Pádraig Brady wrote:
>> On 12/10/2012 07:58 AM, Cojocaru Alexandru wrote:
>>> bash$ yes $(for i in $(seq 1 10); do echo -n a; done) | dd of=big-lines
>>> ibs=11 count=1
>>> 9924+76 records in
The original poster should know better: the best bug reports include
On 12/10/2012 10:03 AM, Eric Blake wrote:
> On 12/10/2012 10:06 AM, John Reiser wrote:
>>> Yes, because a count was specified,
>>> dd will operate in its default awkward but POSIX specified mode
>>> of counting each read() call, even if it returned less than spe
12 matches
Mail list logo
