Late to the party, but in response to Truls email request on
10/18/2013, there's some less sucky lossless compression/decompression
code at https://code.google.com/p/miniz/ (Zip/deflate zlib
compatible, small, fast) and https://code.google.com/p/lzham/
(nearly LZMA compression with much faster
On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote:
4) we need some standard way to separate file names in a stream.
Basically, ^@ is our only refuge, because path can contain any other
character. But maybe newline is good enough?
Why not just play it safe? Would it really add any
Apologies for the spam, some typos here… though you likely knew what I
meant.
On Fri, Oct 18, 2013 at 10:41:55AM -0400, Alex Pilon wrote:
No. ‘du -0 | cut -f 2-’, at least.
`du -a …`
du -a \
| cut -f 2- \
| while read -rd f; do
`while read -rd '' f; do`
Still not portable outside of
On 2013-10-19 11:47, Alex Pilon wrote:
On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote:
4) we need some standard way to separate file names in a stream.
Basically, ^@ is our only refuge, because path can contain any other
character. But maybe newline is good enough?
Why not
A few more suggestions:
bc dc dd file find fmt install killall less make sh time which xargs
(un)zip/gzip/bzip2/lzma/xz
Some of these are more complex than others of course.
-Truls
On 2013-10-18 11:05, Truls Becken wrote:
sh
There have already been a few discussions about the sbase shell, I believe the
last opinion given was that we shouldn't include one.
which
This should be left to the shell usually, since almost everyone uses a hash
table for lookups nowadays, and we
On Fri, Oct 18, 2013 at 11:05:07AM +0200, Truls Becken wrote:
A few more suggestions:
bc dc dd file find fmt install killall less make sh time which xargs
(un)zip/gzip/bzip2/lzma/xz
dd: I suspect this might not be portable if we want an optimized version.
find: Useless, just do `du -a | grep
On Fri, Oct 18, 2013 at 01:40:29PM +0200, Roberto E. Vargas Caballero wrote:
dd: I suspect this might not be portable if we want an optimized version.
find: Useless, just do `du -a | grep blabla'
and a 'find -type d -name -prune -o -type f -perm g=x -exec chmod g-x {}
\; '?
find is
Hi,
On 17/10/13 20:38:54 +0300, sin wrote:
Hi all,
I've been thinking, besides the commands that are already listed in TODO
and all the unimplemented options for existing commands, what other commands
do we want to include in sbase?
May sbase be interested in a small utility called « slow
On 2013-10-18, at 12:29, sin wrote:
find: Useless, just do `du -a | grep blabla'
I'm not interested in disk usage, but finding files based on certain
properties, such as update time, ownership, permissions, etc.
make: Do we really need this in sbase?
Make is a basic tool, useful in lots of
On 2013-10-18 14:03, Simon Lieb wrote:
May sbase be interested in a small utility called « slow » I wrote some
time ago to slow down down input to output ? I can make a patch for
sbase.
I mainly use it with ii and to avoid trigger anti‐flood system and some
other cases.
In my
On Fri, Oct 18, 2013 at 1:07 PM, sin s...@2f30.org wrote:
On Fri, Oct 18, 2013 at 02:04:06PM +0200, Roberto E. Vargas Caballero wrote:
On Fri, Oct 18, 2013 at 03:01:05PM +0300, sin wrote:
On Fri, Oct 18, 2013 at 01:40:29PM +0200, Roberto E. Vargas Caballero
wrote:
I do not consider find(1)
I do not consider find(1) to be elegant in any way. I agree many ppl use it,
including myself, I just wish we could do without this madness.
Well, we can not agree in all the points ;). I see find like the best example of
the eleganty of Unix, do one thing and do it well. Other programs should
Truls Becken dixit:
bc dc
bc can be done on top of dc; BSD does that (the dc uses OpenSSL
for arbitrary-precision numbers).
killall
I object, killall should never, ever, be used. (Try it on a
Solaris system, for example.)
On 2013-10-18, at 12:29, sin wrote:
make: Do we really need this in
On 18/10/2013, sin s...@2f30.org wrote:
find: Useless, just do `du -a | grep blabla'
Yes, this is what one does on Plan 9.
I realize when xargs is useful, I just hate it.
Yep, the basic function is sane, but the other crap, insert mode and
quotation and such, loses.
On 18/10/2013, Truls
On 2013-10-18, at 14:53, Strake wrote:
I'm not interested in disk usage, but finding files based on certain
properties, such as update time, ownership, permissions, etc.
du -a | cut -f 2
Yes, but how do you filter the result on some combination of file attributes?
du -a | cut -f2 | xargs
On Fri, Oct 18, 2013 at 07:53:17AM -0500, Strake wrote:
On 18/10/2013, sin s...@2f30.org wrote:
find: Useless, just do `du -a | grep blabla'
Yes, this is what one does on Plan 9.
Which doesn't necessarily make it right.
I realize when xargs is useful, I just hate it.
Yep, the basic
On 2013-10-18, at 15:45, Truls Becken wrote:
If you want to do it this way around, a command is missing for filtering a
list of file names, as already mentioned by Raphaël. It could be generalised
to a command for filtering stdin by calling a predicate command, e.g:
du -a | cut -f2 | filter
On 18/10/13 20:13:08 +0800, Chris Down wrote:
On 2013-10-18 14:03, Simon Lieb wrote:
May sbase be interested in a small utility called « slow » I wrote some
time ago to slow down down input to output ? I can make a patch for
sbase.
I mainly use it with ii and to avoid trigger
Just for kicks I wrote filter. With this, the above gives same result as:
find . -perm +222
Is this not what stest does?
-emg
On Fri, Oct 18, 2013 at 03:07:41PM +0300, sin wrote:
I do not consider find(1) to be elegant in any way. I agree many ppl use it,
including myself, I just wish we could do without this madness.
I can do without it! I just do
setopt extendedglob
chmod g-x **/*(#q.E^AI)~/**/*
(I hope I
Contributing into the discussion about find.
Most of its selectors are implemented by stest(1); commonly useful
ones that I can think of are -user and -group. However:
1) ostracize me, but I like find one dash, long option style way
more than stest a thousand of letters a-la test. I understand the
Hi all,
I've been thinking, besides the commands that are already listed in TODO
and all the unimplemented options for existing commands, what other commands
do we want to include in sbase?
The current TODO list includes:
diff, expr, printf, tr, unexpand
What about:
od, logname, uuencode,
What about:
od, logname, uuencode, uudecode, mktemp, passwd, su, sed, patch
ed and awk are also missed (yeah, I know they are bigger and
more difficult programs, but they are basic for a system).
--
Roberto E. Vargas Caballero
On Thu, Oct 17, 2013 at 08:38:54PM +0300, sin wrote:
I've been thinking, besides the commands that are already listed in TODO
and all the unimplemented options for existing commands, what other commands
do we want to include in sbase?
[…]
What about:
od, logname, uuencode, uudecode,
Alex Pilon dixit:
Don't od's and hexdump's functionality overlap?
Yes, they (and hd) are normally one binary.
Do we still really need uuencode and uudecode?
Yes!
I often use them, in combination with GNU screen, to
copy/paste files(!) from one tab to the other, when
using other methods (such
Alex Pilon dixit:
Do we still really need uuencode and uudecode?
On Thu, Oct 17, 2013 at 07:46:35PM +, Thorsten Glaser wrote:
Yes!
I often use them, in combination with GNU screen, to
copy/paste files(!) from one tab to the other, when
using other methods (such as rsync or scp/sftp)
Alex Pilon dixit:
I know the trick. I used base64 for that, not uuencode. Don't they
both have the same overhead, other than uuencode's header?
Yes but uuencode is more portable… e.g. the Linux “base64” tool is
rarely installed anywhere and is extremely picky about the formatting
of its input;
28 matches
Mail list logo
