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.
0_smallstuff.patch: Fix missing newlines and so on.
1_dontkillme.patch: Disable Linux's out-of-memory killer for slock if
the system has the configuration knob. That douche hunts small game! Oh
how super fun to come back to an unlocked desktop.
2_dropprivs.patch: Only try dropping privileges if p
>
> The -std=c99 patch is to suppress warnings about using the %llu format
> specifier. It's kept separate in case C99 is undesirable, though.
>
Since we are using long long in other place, I think the best
option is change the standard version to c99.
--
Roberto E. Vargas Caballero
-
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
Accompanying manual patch.
On Mon, Jul 22, 2013 at 11:33 AM, Steve Dee wrote:
> C-[hjkl] are in-page scrolling. C-i and C-o are back/forth page
> navigation, just like in Vim. This frees up C-u for view source, just
> like in Chrome. This patch messes with surfers' muscle memory, but I
> think th
C-[hjkl] are in-page scrolling. C-i and C-o are back/forth page
navigation, just like in Vim. This frees up C-u for view source, just
like in Chrome. This patch messes with surfers' muscle memory, but I
think the consistency with the rest of the world is nice enough to at
least be worth an email. D
BSD-compatible, opinionated df attached. Always prints 512-blocks.
Guesses high on used counts. Untested in Linux because time.
The -std=c99 patch is to suppress warnings about using the %llu format
specifier. It's kept separate in case C99 is undesirable, though.
On Mon, Jul 22, 2013 at 9:55 AM,
On Mon, Jul 22, 2013 at 03:26:09PM +0300, sin wrote:
> Hi all,
>
> This is an initial bare bones df(1) implementation.
> I'm looking for some feedback, I have not put too much thought
> into the code yet (too busy atm).
>
> No manpage yet.
I should also mention, that this naturally breaks on *BS
Am 2013-07-22 14:42, schrieb Silvan Jegen:
The code is really simple and adjusting it to a particular interface
name is trivial. Still, instead of checking for the interface names
you
are interested in, it may be easier to consider all the interfaces
except the loop device.
I will try to find
On Mon, Jul 22, 2013 at 01:40:47PM +0200, Martti Kühne wrote:
> On Sun, Jul 21, 2013 at 3:44 PM, Silvan Jegen wrote:
> > This is an older thread but I just wanted to add some justification
> > for the code I wrote (which seems to have been used by the author of
> > this daemon).
> >
> > On Thu, Ju
Hi all,
This is an initial bare bones df(1) implementation.
I'm looking for some feedback, I have not put too much thought
into the code yet (too busy atm).
No manpage yet.
Thanks,
sin
>From a82f46681f68edafec898cd82b2ca64941440c11 Mon Sep 17 00:00:00 2001
From: sin
Date: Mon, 22 Jul 2013 13:17
On Sun, Jul 21, 2013 at 3:44 PM, Silvan Jegen wrote:
> This is an older thread but I just wanted to add some justification
> for the code I wrote (which seems to have been used by the author of
> this daemon).
>
> On Thu, Jun 27, 2013 at 7:01 PM, Markus Wichmann wrote:
>> [...]
>>> while (fgets(b
Hi,
Added sha512sum(1). No support for -c at the moment.
I've also updated CFLAGS with -Wno-long-long.
Added sha256.h and sha512.h in HDR as well.
At this point we could have a helper function in util/
to parse the checksums in files so we can easily support
the -c flag in md5sum, sha1sum and s
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
26 matches
Mail list logo
