[Resend?] Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Bjartur Thorlacius
On 07/17/2013 06:13 PM, Calvin Morrison wrote: I rely heavily on unioned directories (go plan9!) so mine tend to get large when working with many large datasets. Does anyone use large directories often? Unices avoid large directories to scalability problems like the one you're trying to solve.

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Galos, David
> > What's the bottle neck here? > > Looking up the filenames and reading them, printing them to standard > out and then wc parsing for all the \n characters. None of the time comes from wc. Changing from ' | wc -l' to '> /dev/null' creates no speedup at all. ls's bottlenecks come almost entirely

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Szabolcs Nagy
* Szabolcs Nagy [2013-07-18 18:51:09 +0200]: > PATH_MAX is posix and should be defined in limits.h > FILENAME_MAX is iso c and is defined in stdio.h (usually PATH_MAX-1) sorry i was wrong about the -1 FILENAME_MAX is buffer size, not string length

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Szabolcs Nagy
* Markus Teich [2013-07-18 18:37:57 +0200]: > > isn't PATH_MAX a GNU extension? > no, actually gnu hurd was a proponent of unlimited paths (so any file operation has unbounded latency on hurd only limited by the address space) PATH_MAX is posix and should be defined in limits.h FILENAME_MAX is

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Markus Teich
Am 2013-07-18 17:33, schrieb Markus Wichmann: Also, there already is a constant for the maximum path length of a file. It's called PATH_MAX and already includes the NUL byte. isn't PATH_MAX a GNU extension? --Markus

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Calvin Morrison
On 18 July 2013 11:33, Markus Wichmann wrote: > On Wed, Jul 17, 2013 at 01:23:33PM -0400, Calvin Morrison wrote: >> Hi guys, >> >> I came up with a utility[0] that i think could be useful, and I sent >> it to the moreutils page, but maybe it might fit better here. All it >> does is give a count of

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Strake
On 17/07/2013, Calvin Morrison wrote: > I came up with a utility[0] that i think could be useful, and I sent > it to the moreutils page, but maybe it might fit better here. All it > does is give a count of files in a directory. $ ls | wc -l > I was sick of ls | wc -l being so damned slow on larg

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Markus Wichmann
On Wed, Jul 17, 2013 at 01:23:33PM -0400, Calvin Morrison wrote: > Hi guys, > > I came up with a utility[0] that i think could be useful, and I sent > it to the moreutils page, but maybe it might fit better here. All it > does is give a count of files in a directory. > > I was sick of ls | wc -l

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-18 Thread Dmitrij Czarkoff
On Jul 17, 2013 7:39 PM, "Calvin Morrison" wrote: > > What was the last time you used the reverse polish notation calculator > that precedes the invention of C? It is the calculator I always use. Dmitrij D. Czarkoff

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Nick
Quoth Chris Down: > On 17 July 2013 19:43, Calvin Morrison wrote: > > Could we focus on the merit of the utility? > > I cannot imagine any period in time where this would have been useful > for me over a simple `set -- * && echo "$#"', but whatever floats your > boat. Dependencies are much more c

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Bjartur Thorlacius
On 07/17/2013 06:13 PM, Calvin Morrison wrote: I rely heavily on unioned directories (go plan9!) so mine tend to get large when working with many large datasets. Does anyone use large directories often? Unices avoid large directories to scalability problems like the one you're trying to solve.

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
On 17 July 2013 14:07, Roberto E. Vargas Caballero wrote: >> > Could we focus on the merit of the utility? >> >> I cannot imagine any period in time where this would have been useful >> for me over a simple `set -- * && echo "$#"', but whatever floats your >> boat. Dependencies are much more costl

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
On 17 July 2013 13:58, Chris Down wrote: > On 17 July 2013 19:43, Calvin Morrison wrote: >> The name still this has nothing to do with the utility of the >> statement. Please focus the conversation on that. > > If you are going to release things to mailing lists (especially this > one), you are g

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Roberto E. Vargas Caballero
> > Could we focus on the merit of the utility? > > I cannot imagine any period in time where this would have been useful > for me over a simple `set -- * && echo "$#"', but whatever floats your > boat. Dependencies are much more costly than a small amount of time > saved (and dirs with >100k file

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Chris Down
On 17 July 2013 19:43, Calvin Morrison wrote: > The name still this has nothing to do with the utility of the > statement. Please focus the conversation on that. If you are going to release things to mailing lists (especially this one), you are going to have to stop acting so personally offended

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Jacob Todd
Yesterday. On Jul 17, 2013 1:39 PM, "Calvin Morrison" wrote: > I know there is a naming conflict, what does that have to do with the > usage of the program? > > What was the last time you used the reverse polish notation calculator > that precedes the invention of C? > > Thank you, > > Calvin > >

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
Thank you for your input Evan, I've decided that renaming the file would probably only take one command, and so I think another name might be possible to use. Could we focus on the merit of the utility? Thank you, Calvin On 17 July 2013 13:42, Evan Gates wrote: > Most of the time I have an HP

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
Fine, I retract my statement. The name still this has nothing to do with the utility of the statement. Please focus the conversation on that. Calvin On 17 July 2013 13:40, Chris Down wrote: > On 17 July 2013 19:38, Calvin Morrison wrote: >> What was the last time you used the reverse polish n

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Evan Gates
Most of the time I have an HP-97 sitting on my desk. But when I don't, I use dc.

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Chris Down
On 17 July 2013 19:38, Calvin Morrison wrote: > What was the last time you used the reverse polish notation calculator > that precedes the invention of C? Are you serious? I use dc all the time. Just because you don't use it, don't assume others don't. I find dc to be my calculator of choice.

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
I know there is a naming conflict, what does that have to do with the usage of the program? What was the last time you used the reverse polish notation calculator that precedes the invention of C? Thank you, Calvin On 17 July 2013 13:36, wrote: > dc - desk calculator > > http://man.cat-v.org/

Re: [dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread p37sitdu
dc - desk calculator http://man.cat-v.org/plan_9/1/dc http://man.cat-v.org/unix-1st/1/dc

[dev] coreutils / moreutils - DC a directory counter

2013-07-17 Thread Calvin Morrison
Hi guys, I came up with a utility[0] that i think could be useful, and I sent it to the moreutils page, but maybe it might fit better here. All it does is give a count of files in a directory. I was sick of ls | wc -l being so damned slow on large directories, so I thought a more direct solution