Im just trying to keep y'all consistent
On Jul 22, 2013 6:37 PM, "Chris Down" wrote:
> On 23 July 2013 00:31, Calvin Morrison wrote:
> > Okay so then should we remove the sort option from ls altogether? It
> > isn't very suckless, and can be easily achieved with ls | sort
>
> If you don't unders
On 23 July 2013 00:31, Calvin Morrison wrote:
> Okay so then should we remove the sort option from ls altogether? It
> isn't very suckless, and can be easily achieved with ls | sort
If you don't understand the difference between innately desirable
properties and configurable processing, you are s
On 22 July 2013 18:18, Chris Down wrote:
> On 22 July 2013 23:44, Calvin Morrison wrote:
>> Why? Why is it ridiculous to want to be able to support medium sized
>> file directories, for example thousands of frames of a video, DNA
>> sequencing files and others I often have are in large sets of fi
On 22 July 2013 23:44, Calvin Morrison wrote:
> Why? Why is it ridiculous to want to be able to support medium sized
> file directories, for example thousands of frames of a video, DNA
> sequencing files and others I often have are in large sets of files,
> and don't have any sub division that is
Supporting large directories is fine. Adding new tools which most
people will never have a need for is not, and adding flags to ls every
time we think of a new use case is how GNU ended up with their mess.
An optimized "ls -U" is supporting large directories. A tool to count
them is a special purpo
On 22 July 2013 17:41, Chris Down wrote:
> On 22 July 2013 23:27, Calvin Morrison wrote:
>> This set command is simple, but still takes a long time, because the shell
>> spends a long time doing the globbing of the *
>
> In any case that it matters, you are doing filesystem structuring wrong.
>
On 22 July 2013 23:27, Calvin Morrison wrote:
> This set command is simple, but still takes a long time, because the shell
> spends a long time doing the globbing of the *
In any case that it matters, you are doing filesystem structuring wrong.
Chris Down dixit:
>If you really care, any POSIX shell should be able to do this as long
>as you don't hit ARG_MAX:
>
> set -- * && echo "$#"
I think ARG_MAX may not be relevant here… but globbing * usually
sorts, and shells don’t always use the fastest algorithms…
… but OTOH, if you have that
On 22 July 2013 17:07, Chris Down wrote:
> On 22 July 2013 18:52, Charlie Paul wrote:
>> But now we are looking at an even more obscure situation.
>
> If you really care, any POSIX shell should be able to do this as long
> as you don't hit ARG_MAX:
>
> set -- * && echo "$#"
>
This set command
On 22 July 2013 18:52, Charlie Paul wrote:
> But now we are looking at an even more obscure situation.
If you really care, any POSIX shell should be able to do this as long
as you don't hit ARG_MAX:
set -- * && echo "$#"
On 22/07/2013, Charlie Paul wrote:
> But now we are looking at an even more obscure situation.
Yep, in practice, we'll never have newlines in filenames. And the
Titanic will never sink.
The answer here is to use null rather than newline as a separator.
Alas, The Standard says otherwise.
ls | wc -l has more problems, e.g. \n is a legal character in filenames.
-emg
On Mon, Jul 22, 2013 at 1:36 AM, Nick wrote:
> Quoth Martti Kühne:
>> On Thu, Jul 18, 2013 at 9:00 PM, Galos, David
>> wrote:
>> > Based on the discussion in 'coreutils / moreutils - DC a directory counter'
>> >
But now we are looking at an even more obscure situation.
On Mon, Jul 22, 2013 at 9:45 AM, Evan Gates wrote:
>
> ls | wc -l has more problems, e.g. \n is a legal character in filenames.
>
> -emg
>
> On Mon, Jul 22, 2013 at 1:36 AM, Nick wrote:
> > Quoth Martti Kühne:
> >> On Thu, Jul 18, 20
Quoth Martti Kühne:
> On Thu, Jul 18, 2013 at 9:00 PM, Galos, David
> wrote:
> > Based on the discussion in 'coreutils / moreutils - DC a directory counter'
> > I have optimized sbase ls to easily handle large directories. The major
> > change is that ls no longer calls 'lstat' on files if it does
On Thu, Jul 18, 2013 at 9:00 PM, Galos, David
wrote:
> Based on the discussion in 'coreutils / moreutils - DC a directory counter'
> I have optimized sbase ls to easily handle large directories. The major
> change is that ls no longer calls 'lstat' on files if it does not have to.
>
> This patch a
On 18 July 2013 15:00, Galos, David wrote:
> Based on the discussion in 'coreutils / moreutils - DC a directory counter'
> I have optimized sbase ls to easily handle large directories. The major
> change is that ls no longer calls 'lstat' on files if it does not have to.
>
> This patch also add '-
Based on the discussion in 'coreutils / moreutils - DC a directory counter'
I have optimized sbase ls to easily handle large directories. The major
change is that ls no longer calls 'lstat' on files if it does not have to.
This patch also add '-U' which keeps the list from being sorted. When using
17 matches
Mail list logo
