Shells

What shell does /prog/ use?
I've only used bash, but I want to explore my options. So, which shell do you use, and, if you feel so inclined, why?

>>39
>> 1
Please GTFO.

I use cmd.exe

rc (as part of plan9port). The syntax is regular enough that I no longer always need to look up the man page before doing anything, like used to happen with bash.

>>39
facepalm.txt

>>43
rc is pretty cool and Plan 9's idea of a terminal (with none of that pseudographics shit) is better than *nix's.

>>45
Care to elaborate?

>>46
Nah, I'm good.

zsh is the best sh.

sh is the best sh.

for scripting, posix or a real programming language like perl. for interactive use, zsh or tcsh, depending on whether or not the machine is powerful enough to run zsh well.

the best shell is stdin

>>51
a FILE * is not a shell.

>>46
>>47 is not me. I was going to say the same thing, but since that's taken....

rc is cool because it cleans up the script syntax.

Plan 9's terminal does away with the bullshit pseudographics that *nix is infested with (e.g. any curses app ever, Emacs, vi, text art progress bars), making the whole experience cleaner. Since it doesn't have to worry about strange modes of operation, it is free to buffer input, allowing arbitrary editing of your input with both the keyboard and the mouse. Since programs can't dick with previous output, you're free to edit it as well. So if perhaps I "ls" and want to delete a file, I can just type "rm" before its name then execute that text.

You "lose" the ability to make pseudographics apps, but let's face it: this is the future, we all have bitmap displays, and sqeezing graphical programs into the terminal is retarded.

>>53
Plan 9's terminal does away with the bullshit pseudographics that *nix is infested with (e.g. any curses app ever, Emacs, vi, text art progress bars), making the whole experience cleaner. Since it doesn't have to worry about strange modes of operation, it is free to buffer input, allowing arbitrary editing of your input with both the keyboard and the mouse. Since programs can't dick with previous output, you're free to edit it as well. So if perhaps I "ls" and want to delete a file, I can just type "rm" before its name then execute that text.
Did you mean: M-x shell

$ while read -rp "> " i; do echo -e '#include <stdio.h>\nint main(void){\n'>tmp; echo $i '}'|cat tmp - |gcc -x c -o tmp -; [ -e ./tmp ] && (./tmp; rm tmp); done
printf("lol\n");
lol
>

>>55
#!/bin/sh
name=`basename $0`
while read -rp "$PS2" i
do
 temp=`mktemp ${name}.XXXXXX.c` || (echo "FUCK!" && exit 1)
 echo "#include <stdio.h>" > $temp
 echo "int main(){$i}" >> $temp
 tcc -run $temp
 rm $temp
done

>>54
Wat. No. The only thing more retarded than a pseudograhical program is running a proper CLI inside one. Or even worse, using your graphics display to emulate the look of a terminal in order to get pseudographics to run a CLI in.

>>57
Now your thinking with UNIX.

I use bash.  I should learn some others though.

Is it just me, or is the ``DON'T TYPE STUFF HERE'' field now visible?

>>60
what do you mean?

>>60

It is w3m.

>>62

Forgot an IN in there.   Lack of sleep. yyeeeeaaaaa

>>53
Do not want ;_;

I love character-based UIs. They are pretty darn fast, efficient, and nice to get stuff done. I'm from the Norton Commander (now FAR Manager and its toy Linux counterpart Midnight Commander) school. While I use and love GNU/Linux except when playing games, one of the things I think GNU/Linux (and any UNIX system for that matter) have to improve is character-based application support: UNIX terminals blow, the way the keyboard is mapped with escape sequences is pig disgusting, let alone the special voodoo for cursor positioning, colours, etc. I'd like GNU/Linux to feature a console like that of Windows (which is about the only thing I like from Windows, though few people use it properly with the *W Unicode functions): one that handles colour attributes properly, has appropriate functions for cursor positioning (and some functions for console properties that should be best left to the console interface), and you get a regular Windows event queue, which means you receive scancodes (no more terminfo and ^]]~334m;56d;haxanus]; insanity). This is great for character-based applications, though Windows lacks better fixed-spacing Unicode fonts and console programs.

>>64
In what way does running in a terminal benefit an application? Take FAR Manager, or OFMs in general, for example. What is the console doing for it but messing with its resizability (a weirdness of cmd.exe's family, afaik), limiting it to the use of fixed-pitch fonts (which are nearly always less horizontally space efficient than proportional fonts which can remain readable while being more compact on average) and eliminating the possiblity of previewing images in the Quick View pane?

Until playing with Plan 9 I might have said the same thing as you, but it taught me that I don't love character-based UIs so much as I hate GUI designers. Plan 9 is the only desktop I've seen that applied graphics to correcting the shortcomings of straight CLI programs (e.g. ed->sam) without confabulating buttons and widgets and ohgodimdrowningingradients.

>>65
In what way does running in a terminal benefit an application?
1. Speed. Krusader or any other attempt for a fully graphical OFM is pig disgustingly slow.
2. Enforced usability. Any graphical OFM I've seen is pestered with icons, toolbars and worthless bullshit wasting space and making it look like a Hong Kong street. You cannot add useless bullshit to the application if you can only use text.
3. Terminal support. It's easy to do in text, hard to do with a graphical OFM. IIRC Krusader almost got it right, but you can't use both the panels and the command line at once and have to switch with the mouse which is, again, pig disgusting.

limiting it to the use of fixed-pitch fonts
You mean the proper font that makes everything look right and filenames line up nicely?

eliminating the possiblity of previewing images in the Quick View pane?

A matter of personal taste, but I don't need that feature, nor any kind of expensive preview. If I want to see a file I'll open the appropriate full-screen minimalistic program for that. At the very best I'll accept some libaa voodoo and w3m rendering for HTML, as in Midnight Commander (I also integrated that into FAR Manager).

>>64
You could implement all that for Linux if you wanted to, but you'd still have to use Curses to get your applications running on VT100s and god knows what.

>>66
You mean the proper font that makes everything look right and filenames line up nicely?
Why the fuck would you need monospace in order to line up columns?  That dickheaded mentality of yours of purely relying on bullshit hacks dependent on clinging onto old bullshit limitations is why computer science is so retardedly fucked up.  Go eat shit and die, and let the rest of the world move forward.

scheme shell, fags.

zsh. Call me when bash has proper wildcard tab completion and similar stuff.

>>67
I don't give a shit about the VT100, and you shouldn't either. 99.999999999999999999999999999999% of the people running GNU/Linux have a keyboard which has, at least, something resembling a PC keyboard with no less than 100 keys, supports key down and up scancodes, and can display (or at the very worst gracefully ignore) colour attributes. What we need is a console protocol (not X, not plain text with escape shit) for console applications which can run locally or over a remote shell.

>>68
Are you by any chance a first-year student frustrated that Computer Science is not about dragging cute icons around like you do in Windows Solitaire?

First of all, like anybody I have a huge collection of hentai, anime, ripped TV series or all of these, and I like to see filenames such as a01.jpg and f01.jpg line up properly. Second, it's much faster than using a full-fledged graphic system. Third, it's a matter of aesthetics: I like having fixed character cells, just like I like window snapping and anything that looks fixed and solid. It also helps to prevent idiots from making idiotic GUIs.

>>66
1. Speed. Krusader or any other attempt for a fully graphical OFM is pig disgustingly slow.
Got nothing to do with being graphical. Blame poor development priorities.
2. Enforced usability. Any graphical OFM I've seen is pestered with icons, toolbars and worthless bullshit wasting space and making it look like a Hong Kong street. You cannot add useless bullshit to the application if you can only use text.
But you can not add useless bullshit to the application when you use a bitmap display.
3. Terminal support. It's easy to do in text, hard to do with a graphical OFM. IIRC Krusader almost got it right, but you can't use both the panels and the command line at once and have to switch with the mouse which is, again, pig disgusting.
Nice for lazy devs, but so what?
You mean the proper font that makes everything look right and filenames line up nicely?
What display errors are you envisioning?
A matter of personal taste, but I don't need that feature, nor any kind of expensive preview. If I want to see a file I'll open the appropriate full-screen minimalistic program for that. At the very best I'll accept some libaa voodoo and w3m rendering for HTML, as in Midnight Commander (I also integrated that into FAR Manager).
It falls in my "would be nice" column anyway. It's not like I'd lose anything when not using it, and it would be damned handy when I'm trying to find an image in a directory with lots to be able to scrub through with the quick view pane. Ditto for video, in-place preview would be awesome.

Don't get me wrong, we share some gripes with most GUI programs, but as far as I can tell, none of those gripes have anything to do with bitmap displays per se. Can't you envision a better future with me, a future with output devices chosen to maximise usability and capability?

>>72
1. Speed. Krusader or any other attempt for a fully graphical OFM is pig disgustingly slow.
Got nothing to do with being graphical. Blame poor development priorities.
It does; there's a lot more work when you're to draw bitmaps in various formats, calculate gradients, etc. over just rendering a fixed-spacing bitmap-cached font (which is often hardware-accelerated). Also, X is probably fucked as it's always going to be kinda slow. (And GTK is something else. I can run an errand as I wait for it to fully refresh.)

2. Enforced usability. Any graphical OFM I've seen is pestered with icons, toolbars and worthless bullshit wasting space and making it look like a Hong Kong street. You cannot add useless bullshit to the application if you can only use text.
But you can not add useless bullshit to the application when you use a bitmap display.
I don't quite understand what you meant. Of course you can; you can pest it with stupid icons and bullshit.

>> 3. Terminal support. It's easy to do in text, hard to do with a graphical OFM. IIRC Krusader almost got it right, but you can't use both the panels and the command line at once and have to switch with the mouse which is, again, pig disgusting.
Nice for lazy devs, but so what?
Oh, so you have to be a developer to use the command line or an OFM? Well then, I'm a lazy dev.

You mean the proper font that makes everything look right and filenames line up nicely?
What display errors are you envisioning?
Not errors, just uglyness.

Can't you envision a better future with me, a future with output devices chosen to maximise usability and capability?
I wish I could, but then users who want an "easy search" icon on their internet and developers willing to satisfy these retards come to my mind.

>>71
First of all, like anybody I have a huge collection of hentai, anime, ripped TV series or all of these, and I like to see filenames such as a01.jpg and f01.jpg line up properly.

Er, yeah... anybody. At any rate, I expect these line up better than you imagine. You can even use a font whose numbers are the same width, if you like.

f01.jpg
f02.jpg
f03.jpg
f04.jpg
f05.jpg
f06.jpg
f07.jpg
f08.jpg
f09.jpg
f10.jpg
f11.jpg
f12.jpg
f13.jpg
f14.jpg
Second, it's much faster than using a full-fledged graphic system.

In 2008? I don't think so, buddy. Maybe faster than the GUI widget orgy of the week, but even then, drawing quickly is not the issue.
Third, it's a matter of aesthetics: I like having fixed character cells, just like I like window snapping and anything that looks fixed and solid.

That's pretty OCD, man.
It also helps to prevent idiots from making idiotic GUIs.
I prefer not to use programs written by idiots to avoid a BAD END for my data.

>>73
It does; there's a lot more work when you're to draw bitmaps in various formats, calculate gradients, etc. over just rendering a fixed-spacing bitmap-cached font (which is often hardware-accelerated). Also, X is probably fucked as it's always going to be kinda slow. (And GTK is something else. I can run an errand as I wait for it to fully refresh.)

It's all in what you choose to draw. Depending on the speed of your terminal emulator, a natively graphical program could draw faster than the text-mode version.
I don't quite understand what you meant. Of course you can;
you can pest it with stupid icons and bullshit.

I meant you can not add them. Can refrain from adding them.
Oh, so you have to be a developer to use the command line or an OFM? Well then, I'm a lazy dev.

You have to be an OFM developer to be personally affected by the ease of embedding a command line into your OFM.

>>75
Crap. Quote failure.

>>74
Even if numbers have the same width (they always should, in non-shitty fonts), they'll fuck up whenever they're hex or letters are used to divide by section or volume, or to mark special pages.

In 2008? I don't think so, buddy. Maybe faster than the GUI widget orgy of the week, but even then, drawing quickly is not the issue.

A framebuffer-based character-based system which can only display characters from a bitmap font on fixed position is bould to be faster. Also, even if you can do it right, the second developers are given unlimited graphics abilities they jump on to XBOX bloated toolkits and start doing the usual shit.

That's pretty OCD, man.
Yes, I wonder if I'm OCD, and I know for sure I'm at least OCPD.

I prefer not to use programs written by idiots to avoid a BAD END for my data.
Oh, so you use a Lisp Machine (or, at best, a GNU system without X)? Because any modern system is bound to be plagued with crap. Just look at the most popular desktop environments: Windows, OS X, KDE 4 and GNOME are all written for complete retards. Every new version is more retard-friendly and less useful for real work than the previous (this is specially true for KDE 4 and GNOME).

>>75
It's all in what you choose to draw. Depending on the speed of your terminal emulator, a natively graphical program could draw faster than the text-mode version.
I'm thinking of a framebuffer-based character console, not an X terminal emulator.

I meant you can not add them. Can refrain from adding them.
But very rarely people do, unfortunately.

You have to be an OFM developer to be personally affected by the ease of embedding a command line into your OFM.
I'm a OFM user (and at this rate, developer; fucking Midnight Commander sucks and the other ones on GNU/Linux are even worse), and I'm worried because I'm not getting it right in my OFMs. Only Norton Commander, FAR Manager and very few others did it right: a command line which you can use at the same time you browse panels, run commands and see their results (as panels don't have to cover all of the screen; they can very well cover just the upper half).

>>77
s/bould/bound/ (The original version said built, then I reworded and changed into bound, but fucked up.)

I'm a Windows developer, and I have some questions about Unix/Linux in general. What exactly is the difference between a kernel, window manager, OS and shell? I see these terms come up all the time, but I'm not sure what they mean.