Ok. I'm happy to go back to writing patches; I'm glad all the changes got in.
On Thu, Oct 17, 2013 at 12:30 PM, sin wrote:
> On Thu, Oct 17, 2013 at 12:16:19PM -0500, Galos, David wrote:
>> I'll do this tonight, sorry I've been gone so long, a new job and a
>>
I'll do this tonight, sorry I've been gone so long, a new job and a
2-hour-each-way commute kills a lot of time.
> I cherry-picked this over to ubase (with slight modifications to remove
> the unneeded enum and include linux/vt.h and linux/kd.h).
I approve. I'll remove chvt from sbase
>> + while ((r = read(fd, &c, 1) > 0)) {
>> + offset++;
>> + if (isprint(c)) {
>> + span++;
>
> I think is better use the buffer interface here. Calling getc
> will save a lot of system calls and it will improve the performace
> of the application.
N
I have written the manpage, and pushed this. I have also cleaned
up who, and addedthe '-l' flag.
> Good stuff!
Except for the way that strings were handled when adding '-m'
Both ttyname and strrchr could have easily returned NULL, so
that should have been checked for. I've fixed this in the cleanu
> I'm happy to maintain this and maybe host it at suckless.org as
> we do not currently have an ml at 2f30 for easily managing patches.
Good luck, I would be terrified to start maintaining such a project.
Also, mount looks easy to implement, so I'll see if I can whip up
a linux mount for you
> v3 of the who(1) patchset.
Good stuff! I'd rather not push until the manpage
is updated with the m option, though
>> David, let me know if this is ok.
> I KNEW there was something I forgot to apply! I'll try
> to do this tonight.
Applied!
> 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 sha{256,512}sum.
I a
> David, let me know if this is ok.
I KNEW there was something I forgot to apply! I'll try
to do this tonight.
> David, what do you think?
Ideally, sbase should achieve portability through a lack of
system-dependent code. I think it might soon be important to
create a ubase for ugly, unportable stuff. ifconfig, mount
insmod, could live there. Perhaps that would be a better
home for df? Everything else on th
>> Attached diff also checks st_dev, which ought to cover all cases.
> Good catch, I will apply this tonight.
The patch has been applied.
> This might lead to false positive if the tar file is written to another
> device.
>
> $ ~/.sbase/bin/tar cf /mnt/backup/test.tar .config
> ignoring '.config/zathura/zathurarc'
>
> $ find .config/zathura/zathurarc /mnt/backup/test.tar -printf "%i %D %p\n"
> 1259 2050 .config/zathura/zathurarc
> 1
>> Question, what are we to do with sha512sum? It requires some
>> constants to be long long and we are compiling with C89/C90.
>>
>> Any ideas?
> So far, the solution to this has been to use int64_t in stdint.h
> Although that header is only guaranteed in c99, the header tends
> to be available i
> Question, what are we to do with sha512sum? It requires some
> constants to be long long and we are compiling with C89/C90.
>
> Any ideas?
So far, the solution to this has been to use int64_t in stdint.h
Although that header is only guaranteed in c99, the header tends
to be available in c89 mode
> /* public domain sha256 implementation based on fips180-3 */
>
> you may add that it's from the crypt code of musl libc
> in case somebody wants to check upstream changes
I have applied the patch, then moved that line to the top of the
file, and removed the notice about the nonexistent crypt cod
> This patch fixes this issue using the inode number of the tar
> file.
I like this fix; it has been applied. Thank you for sending this as
an attachment.
Good catch, applied.
Applied
> OpenBSD defines strlcpy function, and the declaration is a bit different
> of the static declartion found in tar.c. The duplication of symbol name
> with different type (one extern and other static, one returning int and
> the other returning size_t) caused tar couldn't compile in OpenBSD.
I hav
Applied
> Just to be more consistent.
Applied!
Applied
>> +/*
>> + * public domain sha256 crypt implementation
>> + *
>> + * original sha crypt design: http://people.redhat.com/drepper/SHA-crypt.txt
>> + * in this implementation at least 32bit int is assumed,
>> + * key length is limited, the $5$ prefix is mandatory, '\n' and ':' is
>> rejected
>> + *
>> If we are going to use only in this file then maybe is better use the
>> snprintf
>> directly.
>
> +1 - that makes more sense.
Then, that is what we'll do.
Also, sin, I'm looking over your patches, and I'll try to add them tonight.
> OpenBSD defines strlcpy function, and the declaration is a bit different
> of the static declartion found in tar.c. The duplication of symbol name
> with different type (one extern and other static, one returning int and
> the other returning size_t) caused tar couldn't compile in OpenBSD.
Since
I have applied this patch. OpenBSD users rejoice, you
too can finally experience sbase!
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
> > 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
> It doesn't, as far as I can tell. That implementation comes from OpenBSD's
> who.
Is the utmp file guaranteed to be machine endian? This patch seems to imply
that.
> *environ = NULL;
The linux manpage suggests 'environ = NULL'. Is BSD different in that regard?
I would like to see sbase compile
With Truls' modifications, I have applied the patch. Sbase now
has tar.
Test away,
Dave
> Have you found time to look at my patch David?
I glimpsed at it; I've been busy this week, so I'm taking
some time now to catch up.
I don't think your most recent patch will apply given the
changes to the function arguments in sha1/md5 introduced
with this patch. It should be trivial for you to
>Added mdprint().
> Update $(HDR) in Makefile to avoid build errors
> with sbase-box target.
I have decided to apply this; the net change in code went from
+83 in the first version to a completely bearable +15. If sha512sum,
et c. show up, this is definitely be net win.
> The goto seems uncalled for. An ordinary if does the job equally well.
> Also, I wonder if a mode variable isn't just as simple as the flg array.
Good catches. I probably went through 10 permutations of argument
parsing until I found the current one, so I'm not surprised that I missed
some simpli
> OpenBSD doesn't have utmpx.h or clearenv.
Does it also not have "getutent"? Replacing clearenv with
environ=NULL is fine, though.
> it'd be simple to specify with a ".for", but then it'd be
> BSD-make--specific, and I don't feel like figuring out cross-platform
> makefiles.)
Good, we want nothin
And, here is that patch that I stupidly forgot to attach.
sbase-adding-tar-2.diff
Description: Binary data
Thanks in large part to your information about how you invoke tar, I
believe I have come up with a decent solution. I also was able to
find the structified version of tar I had worked on in the past.
The argument parsing is a bit ugly, so simplifications are welcome,
provided they keep the current
> Renamed from crypt to sum.
I think crypt was a good name. cryptsum made sense as a function,
I think that printing should be removed from cryptsum, though.
Another function, cryptprint (or mdprint) could take a digest, and
a length. I believe this is a better separation of concerns.
v2 was good
> If an empty path is specified with mkdir -p (for example, mkdir -p ""),
> strchr will read beyond the path string. The patch (attached) should fix
> this.
Thanks, applied. Keep the patches coming!
Dave
> {PATH_MAX}
> Maximum number of bytes in a pathname, including the
> terminating null character.[1]
I stand corrected. I have moved the declaration of 'n' to
the beginning of main (which while not technically required
for c89 compliance, is stylistically consistent with the
rest of the project) a
> The patch introduces buffer overflow. sizeof(buf)-1 should be passed
> to readlink().
Furthermore, buf should be made (PATH_MAX + 1) bytes in size, so that
valid paths don't get truncated.
> Let me know if this makes sense.
This is a bit too much. The only changes I will allow in
{md5,sha1}.c are a change from `struct md5*` to `void*`.
That should be entirely sufficient.
> I also see it a lot in scripts, along with using full options instead
> of short--perhaps to be more verbose? So, for compatibility, perhaps it
> is best to allow both.
If you mean GNU --long-options, then never in a million years :) If
you mean both dashed and non, that is likely what I will do.
The attached patch shows my current work on adapting sltar
to sbase. It is functional, but, there are still open questions
regarding tar. The big deal is the argument parsing: I would
like to use the ARG macros in tar, but I'm not sure how that
fits with the average tar invocation.
In short, how
I'm glad I balked, this is much better.
The patch is applied.
The patch is applied.
> Why not just post your work to the list, so it can be reviewed, instead of
> just thinking about adding it?
> You probably will learn better this way. ;)
I need to find my work first ;) It's in a hard drive somewhere.
For now, I will add sltar into sbase, submitting my changes as a patch
later.
> i have cleaned up sha1 as well, but that was not audited for musl
>
> http://port70.net/~nsz/crypt/
They cleaned up very nicely! I would nix the OpenSSL compat
layer in the sbase patches, but still, very nice.
> That's cool. I will spend some time today or tomorrow to re-write the
> code and s
> The types array stood out to me as a bit of a code smell.
> After pondering over it for a couple of minutes, I realized
> that you could just do this:
>
> type = argv[1][0] == 'b' ? S_IFBLK : S_IFCHR;
After some thought, I am inclined to agree. This has been
changed.
> Oh, and you should add tar
I have just applied the attached patch, adding the mknod(1)
command and manpage to sbase.
Enjoy!
P.S. As a matter of list etiquette, I'm not sure whether this
announcement is considered appropriate. I want to give
folks a chance to comment on my changes, but perhaps
I am supposed to count on peop
> Added LICENSE.lpl as well and updated the license and copyright details for
> the md5 code.
I am considering applying this patch. The license is why I have to take
time to think. I'm worried about setting a precedent which allows external
differently-licensed software to be swept into sbase. It
> and also depends on having a non-read only filesystem
> to write too.
You understand that in order to change the target file, the
filesystem needs to be writable, right?
> > It's reasonably fast
> I want faster.
It's so fast that you never even realized that the moreutils
version uses a tempfile
> I'm failing to see the problem with loading everything into memory.
If the next step is "write that to a temp file" there is a big
problem. There's nothing wrong with the present tempfile approach.
It's reasonably fast, it's completely portable (so no crazy getrlimit
or /proc reading). Strace sh
> It also sucks. avoiding a temporary file is the whole point to sponge.
> otherwise:
>
> cat file | grep file > file_temp; mv file_temp file;
Actually, it would be
tmp = $(mktemp)
grep 'foo' file > $tmp
cat $tmp > file
Not only that, but tmpfile(3) is safer with respect to race
co
> doesn't sponge soak up into memory, not into a file?
Soaking up into a file allows sponge to work on large files. It also
greatly simplifies the actual sponge code.
> Fix warning
I have applied the patch for now. It is unfortunate that c89 does not
support '%zu', because that really would have been the right thing to
do.
David Galos
> In my opinion it is okay to have sponge called
> without arguments to write to stdout.
I disagree. The only use case I could think of was
something like this:
sed 's/foo/bar/' file | sponge | tee file | frobnicate
However, that would fail to work as expected, so I have
removed the feature.
> so why keep it executable...
Indeed. chvt.c is now 644.
> Revised patch: this one also matches the usage to the manpage, fixes
> the troff warning in the manpage, and adds a SEE ALSO section to the
> manpage.
I have just applied this, the bug should be fixed.
> In short, would you still hate X11 if someone went and streamlined both
> protocol and implementation? If so, why?
Maybe not, but that's changing both what it is, and what it does. It
would be a fundamentally different program; how is anyone supposed
to speculate on that?
> If the argument is
> Except it does not actually sponge in the stdout case, only when
> writing to file. Perhaps it would be better to drop support for stdout?
> Or cat temp file to stdout at the end? Why does it open a temp file
> when not using it?
Definitely drop stdout support, its existence makes no sense.
To
Isn't this just 'tee [file] > /dev/null'?
> What is your opinion on a shell for sbase?
The shell is a topic around which there is far too much religion.
Sbase should not include a shell.
I've been watching the slcon talks as they appear on youtube, and I
noticed that sbase was looking for a maintainer. I'd be happy to start
maintaining it.
As for the not-yet-in-place philosophy of the project, I see as far as
keeping any system-specific stuff out. So, modprobe/ifconfig/nldev
would
Revised patch: this one also matches the usage to the manpage, fixes
the troff warning in the manpage, and adds a SEE ALSO section to the
manpage.
sbase-fix-seq.diff
Description: Binary data
> Indeed, to quote the Plan9 manpage: "ARGF must be called
> just once for each option argument. " I will submit a patch making use of
> a temporary variable.
In addition to adding and using a temporary variable to fix the
ARGF() problem, I also shrunk the switch on argc to be shorter
and more con
> Printing the format string in validfmt() shows that it is correct.
> Printing after 'fmt = ARGF();' in line 33 shows clipped format. I have
> no idea how ARGF works and cannot troubleshoot past that. Thanks.
Indeed, to quote the Plan9 manpage: "ARGF must be called
just once for each option argum
> Maybe now?
I would:
* submit as a patch
* write a manpage
* add usage
* eprintf something upon failure.
> Implemented comm(1). I have not tested this very thoroughly so take it with
> a grain of salt.
Dangit! You beat me to it! I wrote this just last night, and was about
to make the manpage.
sbase-add-comm.diff
Description: Binary data
> Or are you limiting this to pure ansi instead of posix?
I'm just trying to conform with the rest of sbase. The CFLAGS include
`-ansi -pedantic -Wall` and I don't want my code to compile with
warnings.
> How exactly do you think you are going to be able to work with / create
> files larger than w
Hopefully the spacing in these is up to snuff. Let me know about any issues.
The who command here is extremely basic, no flags, just prints user,
ctty, and time. On the TODO, there were no flags specified, and I
assumed this this was a philosophical choice rather than an omission.
Feel free to cor
Right, but '-ansi -pedantic' is strictly C89. GCC doesn't complain,
but I could imagine there being trepidation around using a C99 header
in a C89 environment (where it is not required).
2013/6/11 Thorsten Glaser :
> Galos, David dixit:
>
>>On GNU systems stdint.h sti
In my implementation of split, the ability to split files into rather
large chunks is important. However, c89 does not provide a 64-bit int
type by default. Although I could manually emulate 64-bit counting, a
uvlong would be far cleaner. Is there a suckless-approved way of using
such an integer in
The only useful changes to nice here are the move of usage, which is
more stylistically consistent with the rest of the source, and the
proper POSIX return value.
I was under the impression that this project includes ARGBEGIN/ARGEND
macros specifically to avoid getopt, so I see no reason to change
Thanks, I will make sure that is correct in the future.
> Thanks foe the patch, but please learn to use whitespaces. I had to
> reindent your whole patch.
I apologize for the extra effort on your part; if I had known there
was a whitespace problem, I would have been happy to fix it and
resubmit.
Could you be a bit more specific about the whitespac
I've attached a patch which updates the TODO, and adds a bunch of easy
utilities to sbase.
Included is
* rmdir
* printenv
* unlink
* sync
* chvt
* chgrp
sbase-add-rmdir-printenv-unlink-sync-chvt-chgrp.diff
Description: Binary data
With the recent interest in sbase, I wrote nice (1) and fixed the
E?ARGF() macros.
Previously, ARGF() would always return the string at the current
argument location, and would wind up processing the arguments as
flags. A local variable '_break' needed to be introduced to correct
those behaviors.
> Thanks, applied. Sorry for the delay.
I'm just glad I could contribute.
> Anyway, pancake's contributing to voidlinux so I'll try void. Any other
> good rolling release distros?
>From the voidlinux page:
Speed, reliability, and flexibility. That's the battle-cry of today's
disgruntled computer geeks. This is what people want with a Linux
distribution, and this is wha
> There shouldn’t be any reason for doing this
> manual hack, which is just a hack to work around a misdesign in
> fontconfig and xft.
I agree, this isn't the sort of thing that I'd like to see in the st
source, but for the poor souls suffering with a misbehaving
fontconfig, it might be a reasonab
> you know what sucks about this patch? there is no command line flag to
> disable aa. whats up.
It never occurred to me that anyone would want aa fonts. This patch
just prevents FcFontMatch or its family from ever messing aa if it is
specified in the user pattern.
st-forcefully-respect-user-aa
I've attached a patch which forcefully prevents fonts from being antialiased.
On some unfortunate configurations, simply adding "antialias=0" is not
enough. Worse yet, even when explicitly set false in the pattern
object, calls to FcFontMatch add antialiasing back in.
A simple call to FcPatternAd
> my keyboard has a scroll wheel, and I currently
> have it hooked via dwm to run an external shell script to
> increase/decrease the volume.
>anyone got any smart ideas about this?
Write a simple volume control daemon, that makes a named pipe. Then,
in dwm call spawn on shell commands that echo
That means I attached the wrong patch, here is the corrected one
9base-compile-with-musl.diff
Description: Binary data
> Is this patch against 9base hg or tarball? It seems that it fails to patch
> against the tarball.
The patch is against the hg tip.
I've attached a patch which allows 9base to be compiled with the
musl-libc, when CC=musl-gcc and -D__MUSL__ is added to the CFLAGS.
It's trivial stuff, a few missing headers, a couple changed function
calls, and it turns out musl defines setjmp as a macro.
David Galos
9base-compile-with-musl.di
For what it's worth, I'd submitted a patch (attached) to Gottox, the
guy who wrote sltar, which added creation support, but he never wound
up applying it.
With that, and pipes to gzip, or bzip2, you can have all the tar
functionality you know and love.
But, at the same time, plan9 tar works well,
I've attached a patch which adds a '-r' flag to tabbed, so that it can
replace a dummy argument in the command with the window id, rather
than appending it to the end.
The purpose of this is to allow
$ tabbed -r 2 st -w '' -e tmux
Which before would've required some annoying temp-file trickery.
It you really want to typeset your e-mails, why not use
markdown?
* It is human readable, so no-one needs any fancy frontend
* You don't need any annoying multi-part nonsense
* After using things like werc, it should already be second
nature to many people.
* Much non-markdown mail also happens
> I guess I like the idea of keeping all the information in the C header
> file. This makes it clean.
Less clean than troff files for the docs, I think. And retrieval is
definitely uglier than "man headername"
> The problem right now is the APIs are kept in a MS Word Office 2010
> .docx file, whi
> 1) do you have a public repository? If not, I'm sure we can get you on
> hg.suckless, or if you prefer git I can set you up on my server.
I don't have a public repository. I'd be fine with this going on
hg.suckelss, but if it can't, it's probably not too hard to set one up.
> 2) how do you fee
> I'll gladly test this out on my netbook on different networks. I'll report
> back in a weekish : )
Thanks a lot! I'm looking forward to it.
I've written a simple (~500 lines) dhcp client, using the plan9 client
as reference. It compiles statically to between 8 and 30K depending
on libc, and gets me onto all the networks I've thrown at it, but
that's a terribly small list.
I thought it might be of use to the people here. The source is
> Your proposed changes are applied.
Glad I could help!
> I still have to insist on checking
> the right side of »end« to be checked for length.
> % seq 5 -1 1.
> should show four digits to thr right.
I agree that this is sensible behavior. GNU seq doesn't do that,
but since when h
> > Using regexes in seq(1) really, really concerns me.
> Not in C.
I've fixed it to use no regex; only goto, loops and string.h stuff;
attached is the patch.
seq-changes.diff
Description: Binary data
> I'm confused about why we need to use a regular expression here. We
> can do this with a few loops and some ifs. Using regexes in seq(1)
> really, really concerns me.
It was really me being lazy-- my evil plan was to pretend that everyone
was cool with them unless someone spoke up. Curses!
> Thanks for your contribution! Please test my munging of both codes!
It's basically all there, a few issues, though:
Checking for any sign is pointless in digitsright. Checking for the minus
sign is wrong in digitsleft, because the format string we create won't
ever print '+'; but since '-' might
> Have you tried the fmtvalid() function? It seems like there is a typo
> where it is used. Such a function would still be useful in the now ex‐
> isting seq.c.
I hadn't tested it when I sent that. I've attached a version with a tested
fmtvalid function, proper support for scientific notation
> Attached is a first shot at seq(1) for sbase. I do not like having to
> juggle data around to play games with sprintf, so if someone has a
> cleaner approach to this program, please speak up.
Unfortunately, there isn't much that can be done. User input is always
sub-par, and unless we want to a
> Thanks, this is very funny in that anyone using a sane shell won't
> suffer. I will definitely use this where I can!
It also completely ruins things for people who symlink sh to bash!
1 - 100 of 103 matches
Mail list logo
