, Shaun Jackman wrote:
When using mkdir
-pm, the specified mode is applied only to the final directory and not
the parent directories
That behavior is required by POSIX; see
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html.
Perhaps an argument could be made for a new
On Tue, 2011-05-31 at 13:06 -0700, Paul Eggert wrote:
On 05/31/11 11:12, Shaun Jackman wrote:
My use case is working in a directory shared amongst a group of users.
My umask is 022. I run
mkdir -pm775 project/subproject
You're typing stuff like that by hand? I'd expect that sort
On Tue, 2011-05-31 at 15:49 -0700, Bob Proulx wrote:
Shaun Jackman wrote:
My use case is working in a directory shared amongst a group of users.
My umask is 022. I run
If you are working among a group of users then you should set your
umask to be 02 instead of 022. That is probably
On Tue, 2011-05-31 at 15:49 -0700, Bob Proulx wrote:
Shaun Jackman wrote:
My use case is working in a directory shared amongst a group of users.
My umask is 022. I run
If you are working among a group of users then you should set your
umask to be 02 instead of 022. That is probably
:46 -0700, Bob Proulx wrote:
Shaun Jackman wrote:
My primary use case for this feature is to create a shell alias:
alias mkdir='mkdir --reference=.'
so that in interactive shells, new directories are created with the same
permissions as their parent directory.
If your primary purpose
Hi,
mkdir has an option -m to set the permission mode of the directory. I
would find it useful for mkdir to have a --reference=FILE option that
works identically to chmod.
My primary use case for this feature is to create a shell alias:
alias mkdir='mkdir --reference=.'
so that in
Hi Chen,
I haven't done any testing yet, but I was planning on doing pretty much
the same sort of tests as Pádraig reported. I tested on a
single-processor machine with 1 MB cache, and I see similar results (see
below). The next step would be to perform the merging in parallel on a
multiprocessor
Hi,
Do any patches exist to fork the merging stage of sort and run multiple
merge processes in parallel? It seems like a relatively straight forward
improvement, especially since a lot of the fork/wait magic has already
been tackled by --compress-program. I wonder what the optimal
--batch-size
On Wed, 2010-02-17 at 13:27 -0800, Chen Guo wrote:
Hi Shaun,
Last year someone named Glen Lenker did something like that, and I
think the patch was rejected because the maintainers didn't see enough
speed up as the number of CPUs got higher.
Thanks. I'll definitely look into this.
On Wed, 2010-02-17 at 14:57 -0800, Chen Guo wrote:
As for buffer size, I highly doubt using 8 mb, even if we're magically
guaranteed to get 100% of the cpu cache, would work better than a larger
buffer.
The main reason would be for larger files, you'd have to repeatedly
Hi Chen,
On Wed, 2010-02-17 at 15:50 -0800, Chen Guo wrote:
I'm suggesting setting the buffer size to the size of the CPU cache; the
sort process has 100% CPU affinity, i.e. no other processes allowed on
that CPU and so exclusive use of the data cache; and the temporary
directory is
On 7/11/06, Paul Eggert [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] writes:
These formats are useful in constructing a time format which is
zero-based and includes a minimum number of arbitrary bases, such as
%Y-%J-%i.%N.
%s.%N would better achieve that goal, no? It has one
12 matches
Mail list logo
