Re: [dev] Re: [sbase] [PATCH] sort: Fix -u option
On Sat, Mar 12, 2016 at 03:48:13PM -0800, Michael Forney wrote: > On Sat, Mar 12, 2016 at 11:46:31AM -0800, Michael Forney wrote: > > In eb9bda878736344d1bef06d42e57e96de542a663, a bug was introduced in the > > handling of -1 return values from getline. Since the type of the len > > field in struct line is unsigned, the break condition was never true. > > This caused sort -u to never succeed. > > This should be "sort -c" (here and in subject). > > Please amend before committing. Thanks, applied!
Re: [dev] Re: [sbase] Portability
On Thu, Nov 26, 2015 at 05:12:17AM -0500, Random832 wrote: > Dimitris Papastamos writes: > > sbase should only contain code that runs on POSIX systems (with some > > minor exceptions) and fallback implementations for non-standardized > > interfaces that can be implemented portably on top of POSIX interfaces. > > So there's no place for fallback implementations _of_ POSIX interfaces > on top of either older POSIX interfaces or non-standard ones? I would like to avoid that for upstream. If you do push the libcompat patchset to the wiki, you can add fallback implementations as needed. > Anyway, here's a patch for some data type issues that came up - more to > do with compiling with all warnings, though the fact that clock_t is > unsigned on OSX helped catch one of them. Applied with some modifications. Thanks!
Re: [dev] Re: [sbase] cal doesn't highlight current day
On Fri, Nov 20, 2015 at 06:53:53PM +, Connor Lane Smith wrote: > On 20 November 2015 at 18:40, Connor Lane Smith wrote: > > I've attached a patch. It's not too bad, although it does have ugly > > escape codes. But I don't actually mind either way. > > Slightly uglier bugfix. I've applied the patch, thanks!
Re: [dev] Re: [sbase] cal doesn't highlight current day
On 20 November 2015 at 18:40, Connor Lane Smith wrote: > I've attached a patch. It's not too bad, although it does have ugly > escape codes. But I don't actually mind either way. Slightly uglier bugfix. cls patch Description: Binary data
Re: [dev] Re: [sbase] cal doesn't highlight current day
On 20 November 2015 at 13:13, FRIGN wrote: > I think there should be no discussion without a patch. I don't want to see > anybody express his opinion here unless he has a patch in his attachments. I've attached a patch. It's not too bad, although it does have ugly escape codes. But I don't actually mind either way. Thanks, cls patch Description: Binary data
Re: [dev] Re: [sbase] cal doesn't highlight current day
On Fri, 20 Nov 2015 08:08:26 -0500 Greg Reagle wrote: > I don't think we need to discuss anything. I think what's missing is a patch. > I think that a patch to highlight the current day would *probably* be accepted > (but I have no authority, just a regular user/developer). I think there should be no discussion without a patch. I don't want to see anybody express his opinion here unless he has a patch in his attachments. This thread has been going on for too long anyway. I'd merge a patch if it's simple. When it sucks and we find out the feature is too difficult to implement, then it won't be accepted. I understand the reasons to include it. Cheers FRIGN -- FRIGN
Re: [dev] Re: [sbase] cal doesn't highlight current day
On Fri, Nov 20, 2015 at 10:48:15AM -0200, Marc Collin wrote: > I really believe this would be a 0% complexity addition Don't believe but demonstrate. Did you write a patch yet? util-linux' cal manpage states: > the day will be highlighted if the calendar is displayed on a terminal. Go ahead. > Left is how it is. Right is how it could be (with current day highlighted). > Does anyone else think this would help a lot those who use cal constantly? I use util-linux' cal approx. 5 times a day, and yes, the highlight is rather important for my everyday usage. As I'm not sure when I will finally get around to setup sbase/ubase on my workstation, I don't feel obliged to implement this myself at the moment. v4hn signature.asc Description: PGP signature
Re: [dev] Re: [sbase] cal doesn't highlight current day
I don't think we need to discuss anything. I think what's missing is a patch. I think that a patch to highlight the current day would *probably* be accepted (but I have no authority, just a regular user/developer).
Re: [dev] Re: [sbase] cal doesn't highlight current day
Here's a screenshot that shows this (very simple) feature and how it's useful. What people think? I really believe this would be a 0% complexity addition and the usefulness would be very high. http://i.imgur.com/RQUz6cR.png Left is how it is. Right is how it could be (with current day highlighted). Does anyone else think this would help a lot those who use cal constantly? Let's discuss! Thanks for your time. On Mon, Nov 16, 2015 at 8:04 PM, Christian Neukirchen wrote: > Manu Raster writes: > >> Marc Collin writes: >> >>> It's one of the commands I use the most, and having the current day >>> highlighted is a pretty great feature. >> >> Another really useful function would be an optional column in the >> calendar displaying 'ISO week dates' (DIN ISO 8601). They are quite >> common in business parlance but I haven't seen them in any cal command >> yet. >> >> It would save a lot of time awkwardly searching for it elsewhere. > > util-linux cal has -w > > -- > Christian Neukirchenhttp://chneukirchen.org > >
Re: [dev] Re: [sbase] [patch] Adding tar v2
With Truls' modifications, I have applied the patch. Sbase now has tar. Test away, Dave
Re: [dev] Re: sbase
On 16 June 2011 02:18, Connor Lane Smith wrote: > An update: I've done this, and added it to the Makefile. It's a little > simpler than doing it by concatenating all the sources, since we don't > need to worry about statics or anything. Currently sbase-box comes out > at 69K statically linked against musl, or 23K dynamically linked > against glibc. That looks much nicer than my script, actually, nicely done.
Re: [dev] Re: sbase
On 11 June 2011 00:40, Connor Lane Smith wrote: > Why not just edit the individual files' main() functions (in a build > directory) and generate a main.c, compile them, and link the object > files together? Don't have to worry about anything except main(), > then. An update: I've done this, and added it to the Makefile. It's a little simpler than doing it by concatenating all the sources, since we don't need to worry about statics or anything. Currently sbase-box comes out at 69K statically linked against musl, or 23K dynamically linked against glibc. So next I'll carry on with the items in TODO. Any contributions are welcome. ;) Thanks, cls
Re: [dev] Re: sbase
On 9 June 2011 23:24, pancake wrote: > support for string mode format in chmod. Now you can do stuff like chmod +x > .. g-rwx , ... I got round to looking at this. I had to change some of it to make it POSIX and so on, but I like the approach (which basically avoids the POSIX's BNF grammar (seriously)). > I had a go at writing one last night, but it didn't work properly due to > static > variables and no one on here seemed to want it so I didn't bother submitting. > Anyway, I had another pop this morning and here's what I got. It's a bit > hackish, but to do the job properly would require a parser so yeah... Why not just edit the individual files' main() functions (in a build directory) and generate a main.c, compile them, and link the object files together? Don't have to worry about anything except main(), then. Thanks, cls
Re: [dev] Re: sbase
On 10 June 2011 06:55, pancake wrote: > On 10/06/2011, at 4:26, Connor Lane Smith wrote: >> No, there's no bug here; size is allocated and memset on the next line. > > Your gcc sucks. Mine reports the error here. Size is only allocated if the > or condition applies which is not something to always happen opening the > doors to use an uninitialized pointer. It's because gcc doesn't understand that eprintf will never return. Add something like __attribute__((noreturn)) to eprintf's prototype and you'll see.
Re: [dev] Re: sbase
On 10 June 2011 14:23, Rob wrote: > Anyway, I had another pop this morning and here's what I got. Also, forgot to mention, you'll need to alter true.c, false.c and tty.c so their main conforms, otherwise it won't compile.
Re: [dev] Re: sbase
On 10 June 2011 04:30, Connor Lane Smith wrote: > The only way this is going to happen is if someone writes a script > which does it automatically, by going through each utility prefixing > their main() functions (in a separate build directory), generating a > common main() which dispatches to the correct places, and then > compiles them. > > That is to say, I'm not going to change the utilities themselves, but > if someone were to write a separate 'boxing' script I'd be happy to > add it to the repo. > > Thanks, > cls I had a go at writing one last night, but it didn't work properly due to static variables and no one on here seemed to want it so I didn't bother submitting. Anyway, I had another pop this morning and here's what I got. It's a bit hackish, but to do the job properly would require a parser so yeah... Thanks, Rob. monolithic.sh Description: Bourne shell script
Re: [dev] Re: sbase
On 06/10/11 14:25, Connor Lane Smith wrote: Hey, On 10 June 2011 06:55, pancake wrote: Your gcc sucks. Mine reports the error here. Size is only allocated if the or condition applies which is not something to always happen opening the doors to use an uninitialized pointer. I wasn't talking about GCC. Step through the logic in your head. What happens if the if statement is false? The program exits. If GCC whines about it it just means it's not very smart. (It doesn't on my machine, but does on my server using an older version.) I'll add the assignment just to silence it, I suppose. cls you are right. you can also silent gcc by specifying an __noreturn__ attribute to the eprintf function.
Re: [dev] Re: sbase
Hey, On 10 June 2011 06:55, pancake wrote: > Your gcc sucks. Mine reports the error here. Size is only allocated if the > or condition applies which is not something to always happen opening the > doors to use an uninitialized pointer. I wasn't talking about GCC. Step through the logic in your head. What happens if the if statement is false? The program exits. If GCC whines about it it just means it's not very smart. (It doesn't on my machine, but does on my server using an older version.) I'll add the assignment just to silence it, I suppose. cls
Re: [dev] Re: sbase
* Anthony J. Bentley [2011-06-09 19:22:47 -0600]: > Don???t we have /dev/stdin for that anyway? > no /dev/stdin, /dev/fd/0, /proc/self/fd/0 are non standard and not always available (even on linux systems)
Re: [dev] Re: sbase
Hi On 10/06/2011, at 4:26, Connor Lane Smith wrote: > On 9 June 2011 23:24, pancake wrote: >> support for string mode format in chmod. Now you can do stuff like chmod +x >> .. g-rwx , ... > > Thanks, I'll get round to looking at this tomorrow. > >> fix uninitialized bug in tail > > No, there's no bug here; size is allocated and memset on the next line. > Your gcc sucks. Mine reports the error here. Size is only allocated if the or condition applies which is not something to always happen opening the doors to use an uninitialized pointer. >> simplify sleep() -- do not use getopt here. > > If a utility takes any arguments I'd like it to refuse invalid flags, > and accept '--'. I dislike inconsistency. > Sleep takes only numeric aegument. My patch works as expected if u pass a string kr a flag. >> maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 ) > > Not POSIX, imo not useful. You could make a separate usleep(1) or > something anyway. Ok > Thanks, > cls >
Re: [dev] Re: sbase
On 9 June 2011 23:25, pancake wrote: > What do you think about creating a single main() in sbase.c that works like > busybox (as a proxy for the rest of binaries) i think this can be interesting > for embeddeds. So reading symlink of argv0 and act accordingly. The only way this is going to happen is if someone writes a script which does it automatically, by going through each utility prefixing their main() functions (in a separate build directory), generating a common main() which dispatches to the correct places, and then compiles them. That is to say, I'm not going to change the utilities themselves, but if someone were to write a separate 'boxing' script I'd be happy to add it to the repo. Thanks, cls
Re: [dev] Re: sbase
On 9 June 2011 23:24, pancake wrote: > support for string mode format in chmod. Now you can do stuff like chmod +x > .. g-rwx , ... Thanks, I'll get round to looking at this tomorrow. > fix uninitialized bug in tail No, there's no bug here; size is allocated and memset on the next line. > simplify sleep() -- do not use getopt here. If a utility takes any arguments I'd like it to refuse invalid flags, and accept '--'. I dislike inconsistency. > maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 ) Not POSIX, imo not useful. You could make a separate usleep(1) or something anyway. Thanks, cls
Re: [dev] Re: sbase
On 10 June 2011 02:32, Connor Lane Smith wrote: > Thanks. I actually decided the name system is better, since only that > is required by POSIX Though we can allow signums for '-s', despite its not being strictly POSIX. cls
Re: [dev] Re: sbase
On 9 June 2011 16:28, Rob wrote: > I was wondering whether to do that or not, it's pretty useful but > there's a fair bit more code. I'll leave it to cls to decide. Thanks. I actually decided the name system is better, since only that is required by POSIX, and it means we can use the same arg parsing as every other util. cls
Re: [dev] Re: sbase
On Thu, Jun 9, 2011 at 6:58 PM, Connor Lane Smith wrote: > On 9 June 2011 13:40, stateless wrote: >> Attached cmp.c and cmp.1. > > Thanks! I'm also not bothering with '-', so I took that out, which > meant we could simplify the code a lot. Don’t we have /dev/stdin for that anyway? -- Anthony J. Bentley
Re: [dev] Re: sbase
On 9 June 2011 13:40, stateless wrote: > Attached cmp.c and cmp.1. Thanks! I'm also not bothering with '-', so I took that out, which meant we could simplify the code a lot. cls
Re: [dev] Re: sbase
On Thu, Jun 9, 2011 at 6:25 PM, pancake wrote: > What do you think about creating a single main() in sbase.c that works like > busybox (as a proxy for the rest of binaries) i think this can be interesting > for embeddeds. So reading symlink of argv0 and act accordingly. please for the love of god no there are already so many packages that do this (busybox, toybox, etc). heirloom does something similar with a 'common.c' or some shit and it makes it a complete pain in the ass to hack on. one file, one utility, please, with certain exceptions for stuff like awk, sed, grep, and sh. if you want busybox, you know where to find it. -- # Kurt H Maier
Re: [dev] Re: sbase
What do you think about creating a single main() in sbase.c that works like busybox (as a proxy for the rest of binaries) i think this can be interesting for embeddeds. So reading symlink of argv0 and act accordingly. On 09/06/2011, at 17:28, Rob wrote: > On 9 June 2011 16:06, Hiltjo Posthuma wrote: > >> I like it, but what about -signalnumber (and maybe -signalname), I use >> -9 all the time :) > > I was wondering whether to do that or not, it's pretty useful but > there's a fair bit more code. I'll leave it to cls to decide. >
Re: [dev] Re: sbase
Here's my contribution: * support for string mode format in chmod. Now you can do stuff like chmod +x .. g-rwx , ... * fix uninitialized bug in tail * simplify sleep() -- do not use getopt here. The chmod patch is not complete at all, but works much better and +x is something many ppl use. About sleep.. The bsd and gnu supprt milisecond resolution for sleep. The manpage doesnt reflects this. But maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 ) http://lolcathost.org/b/sbase.patch On 09/06/2011, at 17:28, Rob wrote: > On 9 June 2011 16:06, Hiltjo Posthuma wrote: > >> I like it, but what about -signalnumber (and maybe -signalname), I use >> -9 all the time :) > > I was wondering whether to do that or not, it's pretty useful but > there's a fair bit more code. I'll leave it to cls to decide. >
Re: [dev] Re: sbase
On 9 June 2011 16:06, Hiltjo Posthuma wrote:
> I like it, but what about -signalnumber (and maybe -signalname), I use
> -9 all the time :)
I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.
#include
#include
#include
#include
#include
#include "util.h"
#define LEN(x) (sizeof(x)/sizeof((x)[0]))
struct
{
const char *name;
int sig;
} sigs[] = {
#define SIG(n) { #n, n }
SIG(SIGHUP), SIG(SIGINT), SIG(SIGQUIT), SIG(SIGTRAP),
SIG(SIGABRT), SIG(SIGKILL), SIG(SIGUSR1), SIG(SIGSEGV),
SIG(SIGUSR2), SIG(SIGPIPE), SIG(SIGALRM), SIG(SIGTERM),
SIG(SIGCHLD), SIG(SIGCONT), SIG(SIGSTOP), SIG(SIGTSTP),
SIG(SIGTTIN), SIG(SIGTTOU), SIG(SIGWINCH)
#undef SIG
};
int num(const char *s)
{
char *end;
int n = strtol(s, &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", s);
return n;
}
int parse_sig(const char *s)
{
int i;
if('0' <= *s && *s <= '9')
return num(s);
if(strncmp(s, "SIG", 3))
for(i = 0; i < LEN(sigs); i++)
sigs[i].name += 3;
for(i = 0; i < LEN(sigs); i++)
if(!strcmp(sigs[i].name, s))
return sigs[i].sig;
eprintf("%s: invalid signal\n", s);
/* unreachable */
return -1;
}
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
int i;
if(argc == 1){
usage:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
i = 1;
if(argv[i][0] == '-'){
if(!strcmp(argv[i], "-s")) {
if(++i == argc)
goto usage;
sig = parse_sig(argv[i]);
}else{
sig = parse_sig(argv[i] + 1);
}
i++;
}
if(i == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; i < argc; i++) {
int pid = num(argv[i]);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
Re: [dev] Re: sbase
> > Ah man, I've just been doing kill.c myself. Lowest SLOC count makes it > into base? > I like it, but what about -signalnumber (and maybe -signalname), I use -9 all the time :)
Re: [dev] Re: sbase
No worries Rob! :)
Re: [dev] Re: sbase
On 9 June 2011 13:54, stateless wrote:
> Arrgh fucking gmail.
+1
#include
#include
#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
char c, *end;
while((c = getopt(argc, argv, "s:")) != -1)
switch(c){
case 's':
sig = strtol(optarg, &end, 0);
if(*end != '\0')
eprintf("%s: not a (signal) number\n", optarg);
break;
default:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
if(optind == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; optind < argc; optind++) {
int pid = strtol(argv[optind], &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", argv[optind]);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
Re: [dev] Re: sbase
On 9 June 2011 13:48, stateless wrote:
> Hi,
>
> Just to be on the same page and we don't start working on the same
> tools. I'll look into implementing id, kill and comm.
>
> Thanks,
> stateless
Ah man, I've just been doing kill.c myself. Lowest SLOC count makes it
into base?
#include
#include
#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
char c, *end;
while((c = getopt(argc, argv, "s:")) != -1)
switch(c){
case 's':
sig = strtol(optarg, &end, 0);
if(*end != '\0')
eprintf("%s: not a (signal) number\n", optarg);
break;
default:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
if(optind == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; optind < argc; optind++) {
int pid = strtol(argv[optind], &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", argv[optind]);
printf("kill(%d, %d)\n", pid, sig);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
kill.1
Description: Binary data
Re: [dev] Re: sbase
Arrgh fucking gmail.
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include
#include "util.h"
static bool lflag = false;
static bool sflag = false;
int
main(int argc, char *argv[])
{
FILE *fp0, *fp1;
int c;
int line, byte;
int ch0, ch1;
int retval;
if ((c = getopt(argc, argv, "ls")) != -1)
switch (c) {
case 'l':
lflag = true;
break;
case 's':
sflag = true;
break;
default:
exit(EXIT_FAILURE);
}
if (argc - optind != 2)
eprintf("usage: %s [-l|-s] file1 file2\n", *argv);
if (!strcmp(argv[optind], "-"))
fp0 = stdin;
else {
fp0 = fopen(argv[optind], "r");
if (!fp0)
eprintf("fopen %s:", argv[optind]);
}
if (!strcmp(argv[optind + 1], "-"))
fp1 = stdin;
else {
fp1 = fopen(argv[optind + 1], "r");
if (!fp1)
eprintf("fopen %s:", argv[optind + 1]);
}
/* spit an error message as well? */
if (fp0 == fp1)
exit(EXIT_FAILURE);
line = 1;
byte = 1;
retval = EXIT_SUCCESS;
do {
ch0 = getc(fp0);
ch1 = getc(fp1);
if (ch0 != ch1) {
if (!lflag) {
if (!sflag)
printf("%s %s differ: char %d, line %d\n",
argv[optind], argv[optind + 1],
byte, line);
else
retval = EXIT_FAILURE;
break;
}
if (ch0 != EOF && ch1 != EOF && lflag)
printf("%d %o %o\n", byte, ch0, ch1);
if (ch0 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind]);
else
retval = EXIT_FAILURE;
}
if (ch1 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind + 1]);
else
retval = EXIT_FAILURE;
}
}
if (ch0 == '\n' || ch1 == '\n')
++line;
++byte;
} while (ch0 != EOF && ch1 != EOF);
if (fp0 != stdin)
fclose(fp0);
if (fp1 != stdin)
fclose(fp1);
return retval;
}
cmp.1
Description: Binary data
Re: [dev] Re: sbase
Small update, attached cmd.c and cmd.1.
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include
#include "util.h"
static bool lflag = false;
static bool sflag = false;
int
main(int argc, char *argv[])
{
FILE *fp0, *fp1;
int c;
int line, byte;
int ch0, ch1;
int retval;
if ((c = getopt(argc, argv, "ls")) != -1)
switch (c) {
case 'l':
lflag = true;
break;
case 's':
sflag = true;
break;
default:
exit(EXIT_FAILURE);
}
if (argc - optind != 2)
eprintf("usage: %s [-l|-s] file1 file2\n", *argv);
if (!strcmp(argv[optind], "-"))
fp0 = stdin;
else {
fp0 = fopen(argv[optind], "r");
if (!fp0)
eprintf("fopen %s:", argv[optind]);
}
if (!strcmp(argv[optind + 1], "-"))
fp1 = stdin;
else {
fp1 = fopen(argv[optind + 1], "r");
if (!fp1)
eprintf("fopen %s:", argv[optind + 1]);
}
/* spit an error message as well? */
if (fp0 == fp1)
exit(EXIT_FAILURE);
line = 1;
byte = 1;
retval = EXIT_SUCCESS;
do {
ch0 = getc(fp0);
ch1 = getc(fp1);
if (ch0 != ch1) {
if (!lflag) {
if (!sflag)
printf("%s %s differ: char %d, line %d\n",
argv[optind], argv[optind + 1],
byte, line);
else
retval = EXIT_FAILURE;
break;
}
if (ch0 != EOF && ch1 != EOF && lflag)
printf("%d %o %o\n", byte, ch0, ch1);
if (ch0 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind]);
else
retval = EXIT_FAILURE;
}
if (ch1 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind + 1]);
else
retval = EXIT_FAILURE;
}
}
if (ch0 == '\n' || ch1 == '\n')
++line;
++byte;
} while (ch0 != EOF && ch1 != EOF);
if (fp0 != stdin)
fclose(fp0);
if (fp1 != stdin)
fclose(fp1);
return retval;
}
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include
#include "util.h"
static bool lflag = false;
static bool sflag = false;
int
main(int argc, char *argv[])
{
FILE *fp0, *fp1;
int c;
int line, byte;
int ch0, ch1;
int retval;
if ((c = getopt(argc, argv, "ls")) != -1)
switch (c) {
case 'l':
lflag = true;
break;
case 's':
sflag = true;
break;
default:
exit(EXIT_FAILURE);
}
if (argc - optind != 2)
eprintf("usage: %s [-l|-s] file1 file2\n", *argv);
if (!strcmp(argv[optind], "-"))
fp0 = stdin;
else {
fp0 = fopen(argv[optind], "r");
if (!fp0)
eprintf("fopen %s:", argv[optind]);
}
if (!strcmp(argv[optind + 1], "-"))
fp1 = stdin;
else {
fp1 = fopen(argv[optind + 1], "r");
if (!fp1)
eprintf("fopen %s:", argv[optind + 1]);
}
/* spit an error message as well? */
if (fp0 == fp1)
exit(EXIT_FAILURE);
line = 1;
byte = 1;
retval = EXIT_SUCCESS;
do {
ch0 = getc(fp0);
ch1 = getc(fp1);
if (ch0 != ch1) {
if (!lflag) {
if (!sflag)
printf("%s %s differ: char %d, line %d\n",
argv[optind], argv[optind + 1],
byte, line);
else
retval = EXIT_FAILURE;
break;
}
if (ch0 != EOF && ch1 != EOF && lflag)
printf("%d %o %o\n", byte, ch0, ch1);
if (ch0 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind]);
else
retval = EXIT_FAILURE;
}
if (ch1 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind + 1]);
else
retval = EXIT_FAILURE;
}
}
if (ch0 == '\n' || ch1 == '\n')
++line;
++byte;
} while (ch0 != EOF && ch1 != EOF);
if (fp0 != stdin)
fclose(fp0);
if (fp1 != stdin)
fclose(fp1);
return retval;
}
cmp.1
Description: Binary data
Re: [dev] Re: sbase
Hi, Just to be on the same page and we don't start working on the same tools. I'll look into implementing id, kill and comm. Thanks, stateless
Re: [dev] Re: sbase
Attached cmp.c and cmp.1.
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include
#include "util.h"
static bool lflag = false;
static bool sflag = false;
int
main(int argc, char *argv[])
{
FILE *fp0, *fp1;
int c;
int line, byte;
int ch0, ch1;
int retval;
if ((c = getopt(argc, argv, "ls")) != -1)
switch (c) {
case 'l':
lflag = true;
break;
case 's':
sflag = true;
break;
default:
exit(EXIT_FAILURE);
}
if (argc - optind != 2)
eprintf("usage: %s [-l|-s] file1 file2\n", *argv);
if (!strcmp(argv[optind], "-"))
fp0 = stdin;
else {
fp0 = fopen(argv[optind], "r");
if (!fp0)
eprintf("fopen %s:", argv[optind]);
}
if (!strcmp(argv[optind + 1], "-"))
fp1 = stdin;
else {
fp1 = fopen(argv[optind + 1], "r");
if (!fp1)
eprintf("fopen %s:", argv[optind + 1]);
}
/* spit an error message as well? */
if (fp0 == fp1)
exit(EXIT_FAILURE);
line = 1;
byte = 1;
retval = EXIT_SUCCESS;
do {
ch0 = getc(fp0);
ch1 = getc(fp1);
if (ch0 != ch1) {
if (!lflag) {
if (!sflag)
printf("%s %s differ: char %d, line %d\n",
argv[optind], argv[optind + 1],
byte, line);
else
retval = EXIT_FAILURE;
break;
}
if (ch0 != EOF && ch1 != EOF && lflag)
printf("%d %o %o\n", byte, ch0, ch1);
if (ch0 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind]);
else
retval = EXIT_FAILURE;
}
if (ch1 == EOF) {
if (!sflag)
eprintf("%s: EOF on %s\n",
*argv, argv[optind + 1]);
else
retval = EXIT_FAILURE;
}
}
if (ch0 == '\n' || ch1 == '\n')
++line;
++byte;
} while (ch0 != EOF && ch1 != EOF);
fclose(fp0);
fclose(fp1);
return retval;
}
cmp.1
Description: Binary data
Re: [dev] Re: sbase
Here is a half-assed old version of chmod, in the vein of v5 chmod.
It has a man page and informative ed-style error messages, but no
recursion or POSIX-style 'symbolic mode expressions.' I'll refactor
it to use util/recurse later. I don't really care about 'symbolic
mode expressions.'
--
# Kurt H Maier
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
int retval, filecount, i;
mode_t mode;
char *input;
mode = 0;
filecount = argc-1;
input = argv[1];
if ( argc < 3 ) {
eprintf("?\n");
exit(EXIT_FAILURE);
}
while ( *input ) {
if (*input < '0' || *input > '7') {
eprintf("?\n");
exit(EXIT_FAILURE);
}
mode = ( mode << 3 ) | ( *input - '0' ) ;
input++;
}
retval=0;
for (i=2; i <= filecount; i++) {
retval = chmod( argv[i], mode );
if (retval != 0) { printf ("? \n"); }
}
exit(EXIT_SUCCESS);
}
chmod.1
Description: Binary data
Re: [dev] Re: sbase
The tac.c i pushed few time ago is magnitudes faster than awk.
That was the reasom why nibble and me wrote it.
On 26/05/2011, at 20:45, markus schnalke wrote:
> [2011-05-26 07:39] Anselm R Garbe
>>
>> Afaik tac sucks more, as it is quite an arbitrary command, not part of
>> Plan 9 and can be imitated with a awk one liner like
>>
>> awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'
>
> Okay, but who want's to type this line by hand?
>
> IMO tac *should be included* in some Unix toolchain, but as a
> shell/awk script, containing this line. This would be software
> leverage.
>
> Unfortunately it seems as if this concept is just too often handed
> over to the administrators. If programs are distributed, people focus
> on performance and write them in C instead ...
>
>
>
>> Don't get me wrong, I think this sbase thing is a great excercise but
>> I really do believe there is more interesting stuff that we should
>> rather focus on.
>
> I fully agree.
>
>
> meillo
>
Re: [dev] Re: sbase
[2011-05-26 07:39] Anselm R Garbe
>
> Afaik tac sucks more, as it is quite an arbitrary command, not part of
> Plan 9 and can be imitated with a awk one liner like
>
> awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'
Okay, but who want's to type this line by hand?
IMO tac *should be included* in some Unix toolchain, but as a
shell/awk script, containing this line. This would be software
leverage.
Unfortunately it seems as if this concept is just too often handed
over to the administrators. If programs are distributed, people focus
on performance and write them in C instead ...
> Don't get me wrong, I think this sbase thing is a great excercise but
> I really do believe there is more interesting stuff that we should
> rather focus on.
I fully agree.
meillo
Re: [dev] Re: sbase
On 26 May 2011 07:39, Anselm R Garbe wrote: > As for sbase I'm still sceptical this is a good idea as it > re-implements perfectly sound 9base tools, but avoids the real tricky > ones such as rc, mk or awk. I, basically, disagree. The Plan 9 tools were written for another operating system: ls has no -a flag, but you can use -q to list the 9P QIDs? Fantastic. You can't distinguish between a failed match and an error in grep, because Plan 9's exit returns a string? Even better. No other utils that I have found are designed just to be simple and hackable, with only a few useful flags, and not all the cruft. There's 9base, but all the benefits Plan 9 brings are totally screwed by the marshalling back into Unix. Using P9P is a compromise, not an alternative userspace. -rwxr-xr-x 1 cls cls 604908 May 26 11:47 9base/cat/cat -rwxr-xr-x 1 cls cls 21268 May 26 11:47 sbase/cat My intention is to build a userspace for Unix which is very simple (see my earlier post), and actually *designed* for Unix, not just a compatibility shim. I tend to prefer Unix tools which are actually, you know, Unix tools. Regarding awk, we should probably use bwk. I haven't decided what to do about make or the shell, yet. Thanks, cls
Re: [dev] Re: sbase
On 26 May 2011 07:18, pancake wrote:
> What about cat and tac? I already pushed tac to 9base few time ago, but it
> was removed.. It fits better in sbase.
Afaik tac sucks more, as it is quite an arbitrary command, not part of
Plan 9 and can be imitated with a awk one liner like
awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'
As for sbase I'm still sceptical this is a good idea as it
re-implements perfectly sound 9base tools, but avoids the real tricky
ones such as rc, mk or awk.
In the end sbase adds up to the already highly diverse universe of
different Unix command implementations, and probably breaks here and
there as it will contain bugs as well. I mean it is a nice effort but
apart from having some busybox competitor the use is rather limited.
Instead I agree with Szabolcs that this idea of having a high level C
API that implements commonly used stuff like the allocatorz, dial(),
etc, seems more valuable.
Don't get me wrong, I think this sbase thing is a great excercise but
I really do believe there is more interesting stuff that we should
rather focus on.
I created 9base because I didn't need to reimplement every command and
because its source roots back to the real Unix inventors. So I expect
their code to be rather stable and sound. For scripts it seems perfect
to rely on 9base as it should behave equally regardless the underlying
OS (granted there were some issues the Szabolcs and others pointed to
with regards to the fmt implementation, but those will be resolved
quickly).
can't really see the value of it.
Cheers,
Anselm
Re: [dev] Re: sbase
What about cat and tac? I already pushed tac to 9base few time ago, but it was removed.. It fits better in sbase. On 26/05/2011, at 7:19, Connor Lane Smith wrote: > Update! > > We've got 20 utilities now: basename, cat, chown, date, dirname, echo, > false, grep, head, ln, ls, mkdir, mkfifo, pwd, rm, sleep, tee, touch, > true, and wc. > > I think the most crucial ones missing are chmod, cp, mv, seq, sort, > tail, test, and uniq. And probably others. Working on it! I've been > given cal, too, which I'll sort out once the more important stuff is > done. > > cls >
Re: [dev] Re: sbase
On Wed, May 25, 2011 at 10:54 AM, pancake wrote: > On 05/24/11 19:12, Rafa Garcia Gallego wrote: >> >> On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen >> wrote: >>> >>> Remotely reminds me of http://code.google.com/p/aoeui/ which also is >>> pretty lightweight, has UTF8, is binary-safe, and has infinite >>> undo. ~7KLOC, no curses dependency. >> >> This reminds me of my very own sandy[1]. Sorry for the blatant publicity. >> >> Ok, mine depends on ncurses, but the again it weights some 1700 SLOC >> only. The idea of using external tools to process text seems quite >> suckless to me. >> >> [1] http://sandyeditor.sf.net/ >> > Wow. sandy sources looks great. I managed to reproduce some segfaults and > I feel not comfortable with a non-hjkl editor. but as long as it's > configurable in > the config.h. Well, I tried to go for an almost modeless editor because I like it better in theory. But I keep falling back to vi(m) to do serious edits, even on the sandy code (shame on me!). Maybe I should try adding two modes to it, see how it plays out. The default bindings are there to be changed, of course. I imagined emacs-like bindings (read bash-like too) would be comfy for most people. About the segfaults, argh! Could you please point them out to me? Or maybe patch them yourself if you have the time :) > What about moving that repo to hg.suckless.org ? Sure! don't I need a SSH account or something? Cheers, Rafa.
Re: [dev] Re: sbase
On 05/24/11 19:12, Rafa Garcia Gallego wrote: On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen wrote: Remotely reminds me of http://code.google.com/p/aoeui/ which also is pretty lightweight, has UTF8, is binary-safe, and has infinite undo. ~7KLOC, no curses dependency. This reminds me of my very own sandy[1]. Sorry for the blatant publicity. Ok, mine depends on ncurses, but the again it weights some 1700 SLOC only. The idea of using external tools to process text seems quite suckless to me. [1] http://sandyeditor.sf.net/ Wow. sandy sources looks great. I managed to reproduce some segfaults and I feel not comfortable with a non-hjkl editor. but as long as it's configurable in the config.h. Great work Rafa! :) What about moving that repo to hg.suckless.org ?
Re: [dev] Re: sbase
On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen wrote: > Remotely reminds me of http://code.google.com/p/aoeui/ which also is > pretty lightweight, has UTF8, is binary-safe, and has infinite > undo. ~7KLOC, no curses dependency. This reminds me of my very own sandy[1]. Sorry for the blatant publicity. Ok, mine depends on ncurses, but the again it weights some 1700 SLOC only. The idea of using external tools to process text seems quite suckless to me. [1] http://sandyeditor.sf.net/
