Shill for a shell

Is it time for Holla Forums to create the one true shell? We could name it shock perhaps, and it needs a logo.

The logo should be an ascii art of the code directory :^⁾
otherwise rip in peaces project

Other choices are Turtle, and we could have a community config distribution called 'Ninja' built with

I wrote a shell once. It could execute programs in PATH and the PWD, as well as navigate directories, but didn't support environment variables, scripting, or anything else. Despite the fact that it was only a few hundred lines of C with no libraries, it was still about half as big as Bash when compiled.

interactive: zsh
scripting: POSIX sh (the nearest implementations are heirloom-sh, posh and finally dash/busybox ash)

So what's the most lightweight (memory-wise) shell? I just want to use it on a system with 24MBs of ram.

stop trying to fit in redditfriend, it doesn't work because you're too new.

I have yet to encounter something I can't do in plain sh, and even though I don't particularly like it, it's the language I use the most.
There's only two things missing from posix for me: subshells and local variables. Thankfully, literally any shell have those two features.
Other than that, most features in Bash are simply shorthands for things that can be done with external/POSIX utilities such as sed, awk and grep, and arrays are often unnecessary as well if you're not an idiot. If you're just going to loop through the contents, you might as well just call a function multiple times, and even if you're not looping, you can use functions/function arguments as a replacement. Worst case? Just use a newline or zero-delimited string and either adjust IFS or use a while read loop.
I'd love to hear about some unmissable feature from Bash, but I'm always leaning towards limiting myself to as-bare-as-possible sh, because portability (even if unnecessary), and because I like minimalism, and prefer to re-use existing tools instead of really ugly sintatic sugar.
Some features I can name from the top of my head are >() and

lists.suckless.org/dev/1704/31319.html

bloated and designed to look gay (the target audience is Mac homos).
Never use it for any scripting.

the main features are riceable "leet hacker" prompt and "better" autocompletion.
archie's choice.

Avoid using it for scripting, because it has a lot of features which
are not supposed to be in a shell language in the first place, like TCP controls, builtin FTP client, curses and so on.
If you need those consider a real language.

Basically the late UNIX® shell. POSIX standard was based on it.
It was rewritten numerous times, thus there are a few subtle differences between forks.
mskh seems to be the most clear-written and documented of all.
Avoid using it for production code (see above).

GNU, and also the production standard.
It's slightly bloated by features like perl-ish regexs, hashes and so on.
It also has a simplictic TCP/UDP support, which is actually quite handy for logging/debuging of distibuted scripts.
If you're using it right you can write pretty robust pid-free scripts.

Honorable mention. Truly non-bloated one, also a lot of syntactic improvements, but doesn't make a lot of sense outside of Plan 9.

If you are to write shell code:

0. RTFM
1. Use bash.
2. Use shellcheck.
3. Keep your script pid-free.
4. Switch to a better language when things begin to get out of hands.

If you just need a shell to type commands in:

0. Stick with default one or use mksh/bash.
1. Learn job control.
2. Learn coreutils/moreutils to make your life easier.

If you need "muh haxor rainbow prompt":

0. Rice .zprompt
1. Suck cocks.

fish is pretty comfy but I tend to find the majority of its features arent actually much of any benefit over the more basic way of doing things.
Some do seem actually beneficial though, like the history autocompletion imo
Mksh serves me pretty well.

95% or so of my commands are simple and don't use anything more complicated than a pipe or output redirection. They're made much more pleasant by fish, and the non-standard syntax doesn't hinder them because they don't use it.

you can rice mksh's prompt its just a pain in the ass and looks like a mess in the rc file

im saying I dont think they actually are made better by fish most of the time.
I can only think of a few cases in which I find fishes features come in handy. Mainly, history autosuggestion some of the time, selecting files that start with special or nonascii characters, and the way it shows whether a command is valid or not before you enter it is margianlly better than having it fail the pressing uparrow and editing it.
then again, I only script simple batch file conversion or renameing and I dont care if those are posix compliant or not, so practically the nonstandard syntax wouldnt be that much of a problem for me. meme minimalism reasons and hte idea that its relatively close to posix so Id be able to do something portable easier later just outweight the (in my opinion) very marginal benefits of fish, by a little bit.
I'm not the guy who saying its for homos, no need to be defensive about it.

FISH because we need a shell for the '90s already.

You know, most people use zsh just for the better completion (zkbd is also pretty cool).

what does pid-free mean?

not even once
aka "redhat/jewdesktop standard"

time to shoot myself

It means that a script doesn't spawn unnecessary processes, like sed, awk or grep. String substitution, pattern matching and globbing should be used instead.

which implies you should've done it at all

...

that ease of doing it wasnt really any priority for the devs. it was, oddly enough, alot easier and neater in openBSD's pdksh, which mir ksh split from because the openBSD devs called their feature requests for oksh stupid. only reason I dont use it is because it cant handle unicode editing and I couldnt get it to do the thing where you get your last command back with uparrow. so its not like only the bloated macfag shell makes ricing relatively easy.
custom riced prompt is nice for reasons other than ricer skiddie 'dont I look like a hacker' memes. Using personalized stuff feels nice(once you settle on what you're happy with and stop changing it every few days).

Friendly reminder that readline (and subsequently bash) has history completion:
C-p: history-search-backwardC-n: history-search-forward
For more shit: gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax

but muh autocomplete menu
Also my prompt is just
if [ -z "$SSH_CONNECTION" ]; then PROMPT="%F{yellow}%~ $fg_bold[yellow]$ $reset_color%f"else PROMPT="%F{yellow}%n@%m %~ $fg_bold[yellow]$ $reset_color%f"fi

There is no bash on my FreeBSD server, only sh, csh and tcsh.

Forgot to say to put the first thing in ~/.inputrc

Python 3

Please tell me you didn't install those, and they just come with your faggot OS.

They come with the faggot OS, no need to worry.

And Linux isn't Unix. Who cares.

For a ridiculously constrained device like that, Almquist shell derivatives will probably be the best compromise between usability and size. Check out dash and busybox ash.

OpenBSD's (k)sh, because it's the default and works well enough.

mksh is an actively developed, portable fork of it, it's the default shell for Android.

Honorary mention: rc

Falling for OpenBSD meme.

Thanks to retarded licensing.

Opinion immediately discarded.

opinion discarded

...

...

Some fixes for this have gone in recently. example: marc.info/?l=openbsd-tech&m=149450979324891
Works for me with the defaults.

Yea, esac, fi and variables named $@ $# or $1 suck, but breaking compatibility this hard? Not even allowing var=value assignments?
Way to fuck things up

I converted mine to shell scripts and put them in ~/bin/. Makes them a bit easier to manage, too. But it was annoying to have to do that.

So for example if I wanted to extract the board from a URL string
url="8ch.net/tech/res/748439.html#748711"
I should do this:

board="${url#8ch.net/*}"board="${board%%/*}"
Instead of
board="$(cut -d/ -f4

Not that user, but:
I understand that in a context of C, but what's wrong with echo, as long as you quote the variable?

Here is POSIX echo pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html. As you can see, almost no echo follows it (they all have options, for example).

unix.stackexchange.com/a/65819

With bash and ksh you could use here-strings and write it more idiomatically.

URL="oxwugzccvk3dk6tj.onion/tech/res/748439.html#748711"IFS=/ read -r PROTO _ HOST BOARD _

Eventually some expert can explain to me, why i had to add bash before every command in a bin/bash script.sh. when i tried to install fluxion on my raspberry with a debian pixel distro.
To execute the script, i had to add bash for every os command line, and after sudo. e.g. sudo bash ./script.sh when executing the script. Else a load of permission denied.
Just change from bin/bash to bin/sh didn't work well.
Do i have to add bash to path or some shit?

You need to make the file executable with chmod +x.

Odd, i tried few times and gave up. Now i had to try again, i have to add -c to the +x, else i cant change permissions.
Could deliver screenshots.

This wiki is a great resource on bash and shell scripting:
mywiki.wooledge.org/BashGuide
sh is not bash, you can not expect sh to run bash scripts.

Copy the command you ran and ALL output and post it here.
something like:$ ./script.shbash: ./script.sh: Permission denied$ ls -l ./script.sh-rw-r--r- 1 fag fag 288 May 21 18:19 ./script.sh$ chmod +x ./script.shchmod: ./script.sh: Operation not permitted

Why would a shell need networking? netcat is a thing. It sounds specially stupid with bash because GNU has their own version of netcat

That shame when, i don't even know how to use ls the right way.

Sorry looks like a bad troll attempt, shouldn't have pushed enter after ls could have typed -x.
The true odd thing is i change +x and it seems that nothing happend, when i change again with -c.

I have been using fish for a couple weeks, but only just discovered that it has an embeded webserver for configuring it. run "fish_config". That won't please the anti bloat crowd, but it did make configuring it with some included themes quite convenient.

I once had to write scripts to update a couple hundred Linux devices out in the field (spread out all over the world) and only thing that saved my ass was sticking to POSIX. The machines were all of various distros and releases, so didn't have at all the same version of shell and utilities. I used Bourne shell constructs only, and limited use of utilities only to the extent supported by POSIX. There was no fallback plan, it had to work the first time because only non-techy operators had access to those machines. I was basically cleaning up many years of halfass deployments. They would just install random distro and whatever version of our custom software, and send it out in the field. It was a huge mess, but my scripts worked, thanks to POSIX.
And that's only one story. I also had to deal with servers running all kinds of versions of Linux, each with their own set of of libraries. That place made me a firm believer of avoiding dependencies as much as possible, and sticking to standards.
From reading Unix newsgroups over the years, I get the impression that a lot of sysadmins consider ksh (not pdksh) the ultimate for shell scripting. I still don't want to deviate from Bourne and POSIX though, when it comes to production stuff. I'll write Perl script if I need more, but avoiding non-standard modules and new constructs that don't work on old Perl 5 from the 90's (because I've logged in to production servers that have ancient Perl and you couldn't upgrade or even just build new CPAN modules since the compiler, libraries, kernel were so old).

You probably failed to strip the binary. Most of the size of an unstripped program comes from useless debugging symbols.

What the shit.

In any case, since the file wasn't executable, your default shell (bash) would not execute it without explicitly invoking bash with the file as an argument. When the file is made executable, bash will use the shebang line, e.g.,
#!/bin/bash
to determine which interpreter (i.e., bash, python2.7, python3.6, perl, etc.) the file is meant for. Otherwise, bash (or some another default shell) will try to interpret the file, which won't work out so well if it's been written for another interpreter.

Note that not all filesystems support unix permissions, NTFS is a noteworthy example. If you try chmod +x on an NTFS partition it just silently fails.

bash

It's a separate Python script that uses SimpleHTTPServer. More reasonable than it initially sounds.

Bash because it has !! and apparently that's a special thing.

Why not just press the up arrow, or control+p?

because you'd have to reach up to your end key and then back down to type doas rather than just typing doas !!

Fair enough.
Bash is not the only shell with that feature, though. zsh has it too.
In fish I'd probably define a function for it like this:
function fuckoff eval "doas "(history | head -1)end

Trigger Warning: Rust

github.com/redox-os/ion

Turns out that function is unnecessarily complicated.
function fuckoff eval "doas $history[1]"end

It came from csh. Also, !! is just one of many things you can do with !

Next time please copy the text instead of taking a screenshot. It makes it easier for the people trying to help you.

You did not show the output of trying to run the script.
What is the output of `mount`?

Learnt alreay soething today, that there is a difference between ext4 ntfs with chmod.
Is this the relevant part?

/dev/sda1 on /media/pi/KINGSTON type vfat (rw,?

user, I'm sorry to break it to you...

Wow this is very nice. Is there a reason it's so overshadowed by other alternative (not preinstalled usually) shells like zsh? I probably won't put this on any servers but it seems choice for desktop/workstation usage.

* Do not assume you have Bash on the target system. Don't think of this as a holy war--just think of it as being presumptuous or rude. $SHELL choice is personal.
* Write as many scripts as possible in POSIX sh. POSIX and its related standards are far from perfect, but they're the best you've got.
* Only write unadorned Bourne shell when you absolutely need to. I have needed to literally once in my whole career.
* Use a system where /bin/sh is a POSIX shell that doesn't tolerate Bashisms (i.e. don't use Arch). If you insist on being an Arch babby, compile dash or a similar sh into your ~/.bin.
* If you're on a Debian-based system (good choice), install the posix-manpages package. Use features only from those pages where possible.

With all that done correctly. use whichever interactive $SHELL you like, even Fish, if you're weird. Just don't script in it for anything if you can possibly avoid it. An interactive shell with Bourne heritage is still preferable as you'll confuse yourself less often and if you do need to port something you wrote in it, it won't be as painful.

Personal taste: I find Bash to be just fine. Ksh isn't available on as many servers. Neither is Zsh, and it's also enormous and insane.

Some more hints:

* "$quote" "$(your fucking)" "${expansions##*/}".
* Don't write it in shell if a sed or awk script would be a better fit. This happens more often than you think. Awk is a small language but it still does a lot more than people typically think.
* Consider your target platform. If you're only going to put it on systems that have Perl, and you really do need Perl, write it in Perl. Not Python though (get off my fucking lawn).
* Start a ~/.local/bin, or ~/.bin, or whatever path you prefer. Drop little scripts in it. Tinker with them.
* Don't use echo. Just stop it. Rip them all out and use printf. There's no advantage to echo at all.
* Prefer scripts to functions. Prefer functions to aliases. Actually, just never use aliases--same issue as echo: there's no advantage to using them.
* Learn parameter expansion. Learn which features of it are POSIX and which aren't. Use only the POSIX ones. Don't use sed, basename, or dirname to chop up filenames if some judicious in-process PE will do it for you (and probably more correctly).
* Avoid "$(subshell expansions)". If you have to use them, carefully note that they strip all trailing whitespace, because one day that will bite you.
* Use $(...) not `...`. The former nests easier.
* If your script is longer than about 50 lines, start considering whether you can break it up into separate scripts in a pipeline, or if it should be in shell at all.
* If you use a function, consider making it generically useful and putting it in a script instead.

This is great, thank you. The package is called manpages-posix though.

opinion discarded

It is, too. Thanks.

seconding this

>IFS=/ read -r PROTO _ HOST BOARD _

I use ZSH because I don't want my shell to be a shell, I need it to be an operating system.

Try eshell.

As already said by

Is Debian what a time machine feels like?

GNU Emacs 25.2.1 (x86_64-apple-darwin16.4.0, Carbon Version 157 AppKit 1504.81) of 2017-04-25
macOS master race.

That's just my stable, reliable build. This is what a time machine feels like.

$unzipUnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
debian oldstable

UnZip 6.00 of 20 April 2009, by Info-ZIP.
Hah, same for mac too. I guess when something works, it works. No need for unnecessary upgrades.

Also checked the bundled version of emacs in macOS Sierra, 25.1.1... So I guess we can call mac stable...?

Are you sure? Have they changed their policy about GPLv3?
Last time I checked (two years ago or something) it was a really old version. opensource.apple.com has version 22, which is ten years old:
opensource.apple.com/source/emacs/emacs-95/emacs/ChangeLog.auto.html

wait, what? why?

It's a user service for running Emacs as a daemon. I ran "systemctl --user enable emacs" and "systemctl --user start emacs", and now emacsclient always starts up instantly because the daemon is started when I log in.
The unit file comes bundled with Emacs 26, and --new-daemon was added to run as a daemon without forking into the background, which is more useful for service managers like systemd.

That's fine and all, but you don't need SystemDicks to do that.

Of course I don't. I used to have something in my shell's .profile that used pgrep, and I later switched to invoking emacsclient with -a=, which starts the daemon if it isn't running yet, which means a long startup time for the first client.
But why wouldn't I do it with systemd now that it's available? I know that people like to complain about systemd doing too many jobs, but managing daemons is entirely appropriate.

Are there any benefits of this over just having emacs --daemon run on login?

It's a way to have emacs --daemon run on login, basically. Are there specific other ways you want to compare it to?
An advantage over a very naive way to make emacs --daemon run on login would be that you only get one emacs even if you log in multiple times.

Start it by cron.
@reboot emacs --daemon

My apologies, I read it wrong. Yeah mac is stuck on GNU Emacs 22.1.1.

That works. The systemd way has some minor conveniences because you can do things to the service through systemctl and journalctl. It also starts at login rather than boot, which may matter on systems where you're not logged in all the time. No major advantages.
But since enabling the service is trivial (even more trivial than adding a line to your crontab) I prefer that, if I'm running systemd and Emacs 26 in the first place.

Windows 10 is the ultimate shell for all tech anons

a shell for children
a shell for faggots

zish user coming through

Fish is the best interactive shell. No reason to use anything else.

But why is it in kandy korn kolors?

Reminder: ring 3 is for peasants

im really happy you've all found a shell you like it just brings warmth to my heart to see you gloating over your exotic shells. bless you people :)

ur cute

powershell in wine

Why Wine?

Because bait.

ayyy lmao

classic shell

mmm whatcha smea-ayy, ohh

/thread

fsh gang represent

...

Which brings a question why there's no other JIT compiled shells around?

there's no reason other than to be a hipster not to use bash

Plain sh is often better for scripting because it has wider support, and fish feels like it was designed by someone who was actually aware they were making a user interface.
Give fish a try. It's different from zsh hipsterism, it considers ricing a symptom of bad design.

The Bourne-Again SHell. It's a standard on GNU, you don't need anything else.

The Ion Shell. It's written in Rust, you don't need anything else.
github.com/redox-os/ion

This user gets it.

I really like oyster shells. They're usually pretty shiny and not hard to poke a hole in to make a necklace or something.>>748439