[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]

/prog/ - Programming

Programming board

Catalog

8chan Bitcoin address: 1NpQaXqmCBji6gfX8UgaQEmEstvVY7U32C
The next generation of Infinity is here (discussion) (contribute)
A message from @CodeMonkeyZ, 2ch lead developer: "How Hiroyuki Nishimura will sell 4chan data"
Name
Email
Subject
Comment *
File
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options
Password (For file and post deletion.)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 8 MB.
Max image dimensions are 10000 x 10000.
You may upload 1 per post.


File: 1425537559593.png (173.98 KB, 1584x735, 528:245, howtoapplythermalpaste.png)

2e3eb1 No.1561

Just dicking around making small shell utilities in C. Any thoughts on this simple print util? Possibility to make it faster, more concise, etc. I'm going to be adding an option tomorrow to take in a format string for the remaining args to expand it's functionality to cover printf.


#include<stdio.h>
#include<string.h>

#define VERSION "0.2"
#define AUTHORS "O.P. Faggot"

void help(char * reason)
{
fprintf(stdout, "%s\nkutils 'print' v%s authored by: %s\nusage: print "
"[<-n> <-s '?'>] <variable>…\ndescrip: prints arguments to the screen "
"in the order they are given\noptions:\n-n\tdoes not print newline after "
"all arguments.\n-s '?'\tprints with separator '?' between each argument; "
"defaults to space.\n", reason, VERSION, AUTHORS);
}

int main(int argc, char **argv)
{
//ensure that argc is not 0 (possibility due to C11),
//quick finish no args for echo-like behaviour (argc == 1)
switch (argc)
{
case 0:
{
return 0;
}
case 1:
{
fputc('\n', stdout);
return 0;
}
}
argc–;
argv++;

char print_newline = 1;
char separator = ' ';

//check for program info args
if (!strcmp(argv[0], "–help"))
{
help("");
return 0;
}
else if (!strcmp(argv[0], "–version"))
{
printf("kutils print v%s\n", VERSION);
return 0;
}

//check for no newline and separator arg
while ((argc != 0) && (argv[0][0] == '-'))
{
switch(argv[0][1])
{
case 'n':
{
print_newline = 0;
break;
}
case 's':
{
if ((argv[0][2] != '\0') && !argv[0][3])
{
separator = argv[0][2];
break;
}
argc–;
argv++;
if (!argv[0][1])
{
separator = argv[0][0];
break;
}
//else falls into error below
}
default:
{
help("Invalid argument");
return 0;
}
}
argc–;
argv++;
}

// print all args separated by separator
while (1)
{
fputs(argv[0], stdout);
argc–;
argv++;
if (argc == 0) break;
fputc(separator, stdout);
}
// print newline at end if not specified otherwise
if (print_newline) {
fputc('\n', stdout);
}

return 0;
}


If you have any small utils like this share 'em here.

fdfaa1 No.1709

>>1561
Unless you are ideologically opposed to the FSF or something, use GNU argp for parsing options or if that is overkill, getopt.

74ceed No.1716

>>1709
Of the GNU coreutils source I've read, I have never seen argp used. I don't use GNU extensions if that is one. All my code compiles with -pedantic.
To be specific I use "gcc -std=c99 -g -O2 -Wall -Wextra -pedantic <name>.c -o <name>".

I extended it to encompass printf as well. Also supports '-e' from echo and adds '-a' to specify a newline. '-f' turns it into printf and ignores all other options. It doesn't support octal and hex inputs or outputting in unicode. GNU printf is inconsistent about input as octal and hex and thus the functionality will not be implemented. Its functionality will be replaced with 'rebase' which should be used to convert numbers to different bases. And printing unicode should be done with a different tool, or this tool should be done in all unicode (which I am not knowledgeable about implementing in C) (I might do it eventually).

http://pastebin.com/wrJdWwv6
Sorry about the code blocks in there.

364dee No.1717

>>1716
It depends what you're doing. If you're implementing something from scratch, for example, for your kernel – suggested by 'kutils', then fine. Otherwise you're just reinventing argp.

364dee No.1718

>>1716
In case you're too lazy to find it yourself:
https://www.gnu.org/software/libc/manual/html_node/Argp.html

dace29 No.1721

OP you write C like its 1989

74ceed No.1726

>>1721
And why is that? While loops, gotos, and realloc aren't hip enough?

74ceed No.1730

>>1717
>If you're implementing something from scratch, for example, for your kernel – suggested by 'kutils', then fine.
In a way, yes. I'm not reimplementing a kernel (k is just a part of my name), it will sit on top of Linux and a tty, but I am replacing the shell and with it the coreutils.The shell will be a Lua interpreter with additional functionality and the coreutils will be replaced with Lua scripts or Lua C API code. I hate bash, and I think a lot of other people do as well. Originally I was looking at Python but determined that it was too large if the shell was to be used in embedded systems. Lua fit the bill perfectly: it's easy to learn and not too complex, very small, interacts with C well, and performs well.

This is just exercise (it's been a while since I've written in C) and me trying to figure out what utilities I should add and what features in those utilities I want to support. After I finish there will be no GNU on my system besides GCC, so I hardly see the reason to use GNU extensions, it simply keeps others from using it on their system without GNU libc.

7cf059 No.1731

>>1716
Neat. You might consider getting rid of the formatter and str_out buffers altogether though; first, even the best-implemented *alloc functions are slow as shit, and second, the standard FILE interface semi-gracefully handles buffering all on its own.


As for my small utility:
>https://clbin.com/a44jF
>https://clbin.com/W3ZnA

The first part is a shell script run by devd to mount external drives as they are plugged in (conveniently, the FreeBSD kernel provides the drive labels through /dev).

The second part is for running umount on drives mounted by the shell script (in practice, it works like an ultra-restricted umount that can be run as an unprivileged user).

I *really* hate desktop environments.

db9796 No.1732

>>1561
how long have you been programming?

a1000e No.1734

>>1726
Casting result of malloc, declaring all variables together
>>1730
what's wrong with bash or GNU software
>>1731
why do you hate desktop environments

74ceed No.1736

>>1734
I guess casting malloc is a bit silly when throughout I ignore other implicit castings. Declaring variables together is good practice though.

I have no problem with GNU or the extensions, but they are not ubiquitous and I do not endeavor to make them so. It's ISO C99 for me. I might look into C11 some time soon, but doubtful I'll adopt it because many people's compilers don't support it. Mine doesn't even support all the features.
Bash on the other hand…
Is slow
The syntax is awful to read and write
Very few features, the features it has are shell utilities written in C (Pipes and std stream redirects are very useful though)
There are many ways to do things and yest there is no standardization to the way things should be done and not all OSes support all methods which becomes a pain when porting scripts
There are no types, everything is a string that needs to be parsed (why can't numbers be numbers and objects be a thing?)
And with as little as it does the executable is four times the size of lua's interpreter and consumes twice the resources at idle.

I really think the shell should be a real language, and bash is not a real language.

7cf059 No.1737

>>1736
>Very few features, the features it has are shell utilities written in C
This is by design. You might say that bash has too many features.
See: Unix Philosophy ("Do one thing and do it well" and "work with strings, because they're all like, awesome and shit" [that second part may have been paraphrased…]); in other words, the purpose of the shell is to run other programs.

>There are many ways to do things and yest there is no standardization

There are actually a few standards and common conventions for Unix-like operating systems, and I've yet to see a case where having more than one way to do things is bad. Also, making a new shell will really only add to the chaos.
See: POSIX (a widely-accepted standard for modern Unix-like systems, including a specification for a shell, which bash extends)

>There are no types, everything is a string that needs to be parsed (why can't numbers be numbers and objects be a thing?)

See: Windows PowerShell (a massive, intricate shell framework built on top of .NET which embodies this concept), Unix Philosophy

>and bash is not a real language.

It has arrays, conditional statements, loops, functions, variables, support for arithmetic, and basic file I/O.
What more could you want?


No arguments on any of your other points, though.


>>1734
>why do you hate desktop environments
1.) xbox huge, and then there are dependencies
2.) "extensible" means "look at all these extra checkboxes we added!"
3.) "customizable" means "you can set your desktop wallpaper to a slideshow!"
4.) Only rarely can you remove unused features without building a modified version yourself, or outright forking it
5.) Almost universally mouse-driven
Every time someone opens a "Preferences" dialog, a kitten gets hit by a truck
6.) muh tiles, where are they?
7.) Pretty graphics are considered an important feature rather than icing on the cake
8.) Often hilarious results in multihead setups
Though admittedly, this is a bit better now.
9.) Either an application is written for the DE, or it sticks out like a sore thumb
Case in point: The GTK+ "double window border" debacle

adeefd No.1744

File: 1426774931820.gif (407.76 KB, 250x250, 1:1, 1419503335753.gif)

>>1736
Niggers…niggers program..niggers everywhere.

8f31bc No.1850

>>1737
I've more or less found Xmonad to host a decent DE that allows you to prioritise functionality over flashing lights, while effortlessly providing you with some niceities (i.e. anti-aliased fonts). I've got a dual-head setup with one 4k monitor and another at 1980x1200, and it works flawlessly; If you've not tried it before or recently, I'd definitely suggest you give it a shot.

e29e30 No.1851

>>1734
>what's wrong with bash or GNU software
It's shit from many perspectives.

55dbbf No.1854

>>1734
Bash continues the GNU tradition of being as bloated and unorthogonal as possible. If you look through the docs you'll see there are mounds of features which all vaguely overlap with each other, yet no unifying logic to tie everything together.

To be fair I use zsh which is probably even worse, but IMO almost all shells are held back by trying to be compatible with some arcane syntax. As far as I know, only fish and plan 9's rc come close to shedding the weight.

7cf059 No.1880

>>1854
>If you look through the docs you'll see there are mounds of features which all vaguely overlap with each other, yet no unifying logic to tie everything together.

As an avid bash user, I can tell you that is absolutely correct. Also, more bugs than an American fast food restaurant. Use it long enough, and you'll start to like it in a kind of fucked up, Stockholm syndrome sort of way.

It could be an excellent shell with some restructuring, though. Thing is, as with all popular software, that would break compatibility with old versions. No major organization would adopt it; they'd have to rewrite all of their existing bash scripts. Which, coincidentally, is also the reason noone (except /prog/ and /gentoo/) uses rc or fish.



[Return][Go to top][Catalog][Post a Reply]
Delete Post [ ]
[]
[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]