Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stronger Shell

m.odul.us

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Stronger Shell

#71

Post by anh79 »

qznc wrote: post #68
anh79 wrote: post #33

Bash is good as a system shell. For interactive shell, zsh/fish/... wins. That's why I only learn Bash. One lesson for everything for both purposes ;)

fish would be better than bash as a system shell as well. More consistent, for example. However, bash is available and usually preinstalled everywhere, in contrast to fish.

I agree. But "fish" is quite strange to me, especially its way to recall history. In "Bash", I can type "^ R" and browser the history very fast. In "fish", I have to type and select with up/down array; it's not easy to browser the history randomly (FIXME).

My #Bash" history has > 96k entries (woh, believe it or not; because of this too big number, "xterm" + "screen" always stuck when exitting; but "urxvt" + "tmux" work perfectly thanks to "urxvt" daemon mode.)

Porting this huge history database from my daily "bash" to "fish" is just a nightmare ... :D

Re: Stronger Shell

#72

Post by anh79 »

anh79 wrote: post #71
qznc wrote: post #68

Earlier quoted context omitted.

fish would be better than bash as a system shell as well. More consistent, for example. However, bash is available and usually preinstalled everywhere, in contrast to fish.

I agree. But "fish" is quite strange to me, especially its way to recall history. In "Bash", I can type "^ R" and browser the history very fast. In "fish", I have to type and select with up/down array; it's not easy to browser the history randomly (FIXME). My #Bash" history has > 96k entries (woh, believe it or not; because of this too big number, "xterm" + "screen" always stuck when exitting; but "urxvt" + "tmux" wo…

(Talking about interactive "fish" shell; but that's the point: I need to be familiar with its interative mode first.)

Re: Stronger Shell

#73

Post by lisivka »

realharo wrote: post #20
barrkel wrote: post #11

Earlier quoted context omitted.

Most bash scripts that I write are extended and more nicely formatted one-liners, packaged up with some help text and sanity checking for easier reuse. Rewriting in a completely different language rather than snipping out the already working text from the terminal seems a little pointless. Your link doesn't really counteract this usage. Your stance seems to be a bit like giving up on writing Javascript because of the…

I mostly just have a problem with the default behavior of ignoring errors and continuing (yes I know it can be overridden). This coupled with the fact that you'll be working almost exclusively with strings, and all the quoting and escaping rules (which can be a huge pain themselves), can easily lead to bugs like this one https://github.com/ValveSoftware/steam-for-linux/issues/3671 . I have written some bash scripts m…

Use "set -ue -o pipefail" at beginning of the shell script for "strict mode". Use "bash-modules" library, which is designed for strict mode. Always quote variables unless you really want them to be parsed by bash.

Re: Stronger Shell

#74

Post by lisivka »

tachion wrote: post #34

What suprises me is how often Bash is being used as 'the shell' and software projects use it, even when they could simply call /bin/sh instead. This is particularly bad for people who port software to other platforms (where BSD systems dont come with Bash, for example) and have to deal with pure shell scripts calling Bash. One recent example is CoreOS/etcd that's currently dropping Bash in favor of Sh, because they s…

Bash is just yet another dependency for a script. Perl script needs perl. Ruby script needs ruby. Python script needs python. Bash script needs bash. What wrong with that?

Re: Stronger Shell

#75

Post by felixgallo »

useerup wrote: post #58
felixgallo wrote: post #40

Earlier quoted context omitted.

I had an opportunity to use PowerShell recently. The task was simple: on a bunch of freshly installed windows 8 boxes, kill a running graphical program of a certain name, copy over new executables, and restart that graphical program. The kind of thing you do essentially constantly on Unix boxes. I urge anyone at all with any interest in PowerShell to give it a shot. Spoiler: it's not possible without an epic level of…

Using the non-aliased verbose form of the cmdlets: $hosts = 'host1','host2','host3' $source = '\\host0\c$\source' $dest = 'c:\dest' $executable = 'C:\Program Files (x86)\Notepad++\notepad++.exe' Invoke-Command -Computer $hosts -ScriptBlock { Get-Process | Where-Object Path -eq $using:executable | Stop-Process -Force Copy-Item -Path $using:source -Destination $using:dest } Explanation: Line 1-4: Set up variables to ma…

hey, this was a pretty good try! But here's what else you need to do:

https://rkeithhill.wordpress.com/2009/05/02/powershell-v2-re...

and if that's not hair-raisingly terrifying enough (note the super-intuitive 'set-item wsman://...' call), you'll quickly find that when you start a program (which you left off) using a script remotely, it doesn't show up anywhere on-screen, despite being authenticated as the logged-in user, but it does show up in the process list. Guess why THAT is.

There are some pretty parts to PS; but they fall apart, at the touch, instantly, like fairy buildings made of dew.

Re: Stronger Shell

#76

Post by setpatchaddress »

anh79 wrote: post #33

Bash is good as a system shell. For interactive shell, zsh/fish/... wins. That's why I only learn Bash. One lesson for everything for both purposes ;)

Programmer time is better spent learning almost any language other than bash. My god, the centuries wasted on minutiae like the stupid "[ is a program, that's why you have to put spaces around it."

And system administrators should use Ruby if given a choice.

Re: Stronger Shell

#77

Post by ridiculous_fish »

anh79 wrote: post #71
qznc wrote: post #68

Earlier quoted context omitted.

fish would be better than bash as a system shell as well. More consistent, for example. However, bash is available and usually preinstalled everywhere, in contrast to fish.

I agree. But "fish" is quite strange to me, especially its way to recall history. In "Bash", I can type "^ R" and browser the history very fast. In "fish", I have to type and select with up/down array; it's not easy to browser the history randomly (FIXME). My #Bash" history has > 96k entries (woh, believe it or not; because of this too big number, "xterm" + "screen" always stuck when exitting; but "urxvt" + "tmux" wo…

Actually fish will import your ~/.bash_history automatically!

Re: Stronger Shell

#78

Post by klibertp »

useerup wrote: post #49
klibertp wrote: post #41

Earlier quoted context omitted.

That's true. I left MS-land years ago, and PowerShell is one of the few things I miss. The only problem with PowerShell is that you need to write C# (or any other .NET language of course) if you want to create a real cmdlet (if I remember the name correctly). Other than that it's a quite nice shell and a sane procedural scripting language (again, with access to most of .NET). The other, general problem with cmdlines/…

> The only problem with PowerShell is that you need to write C# (or any other .NET language of course) if you want to create a real cmdlet What you say was true for PowerShell 1.0. Since 2.0 you have been able to create cmdlets and modules through scripting. An "advanced function" with [CmdletBinding] attribute is a full-featured cmdlet. Now at version 5.0, PowerShell even has native syntax for creating classes and e…

> What you say was true for PowerShell 1.0.

Ok, I said I used it many years ago :) Thanks, it's good to know.

About the console/terminal emulation: PowerShell has way saner architecture in this regard. I wasn't clear enough, what I wanted to say is that on Linux we have terminal emulators which try their best to emulate (hence the name) physical hardware from ages ago. I was both impressed and seriously disturbed when I read this: http://www.linusakesson.net/programming/tty/ In short:

> In present time, we find ourselves in a world where physical teletypes and video terminals are practically extinct. Unless you visit a museum or a hardware enthusiast, all the TTYs you're likely to see will be emulated video terminals — software simulations of the real thing. But as we shall see, the legacy from the old cast-iron beasts is still lurking beneath the surface.

PowerShell simply ignores all the legacy cruft and doesn't even try to be compatible with 1940-era hardware. Which is, in my opinion, better and a sound technical decision, which resulted in much better architecture. The problem is that most Linux cmd-line apps expect to work under terminal emulators, not inside a modern environment PS provides.

Re: Stronger Shell

#79

Post by klibertp »

toothbrush wrote: post #60
klibertp wrote: post #16

Earlier quoted context omitted.

Zsh is largely compatible with bash's quirks, and then layers lots of weird things of its own on top of that. ZSH is a great, very powerful shell which I use and enjoy, but it's not any of: "simple", "consistent", "fast" or "lightweight".

OK. Fair enough. I use zsh (only scratching the surface) because years ago it turned out that the completion "seemed" to me to be much more powerful ( e.g. , fuzzy matching, substring matching, etc. ), but i haven't invested time to become a wizard. Do you (or anyone else here) endorse a shell which is worth becoming a wizard in? I'm thinking perhaps eshell or simply zsh-in-M-x-shell is perhaps a good starting point,…

Don't go the eshell route unless you're prepared to learn Elisp very well and then write a ton of custom Elisp code. Take a look at its documentation:

> Eshell is _not_ a replacement for system shells such as ‘bash’ or ‘zsh’. Use Eshell when you want to move text between Emacs and external processes; if you only want to pipe output from one external process to another (and then another, and so on), use a system shell, because Emacs’s IO system is buffer oriented, not stream oriented, and is very inefficient at such tasks. If you want to write shell scripts in Eshell, don’t; either write an elisp library or use a system shell.

And yes, I never managed to make auto-completion work really well in M-x shell (or eshell).

One possible shell env you might be interested in is IPython. It's a Python REPL with support for launching external programs, shell-like variable substitution and much more. Coupled with qtconsole it makes for a great shell-like experience. I was using IPython under Windows as my shell for awhile, before switching to PowerShell.

Re: Stronger Shell

#80

Post by useerup »

felixgallo wrote: post #75
useerup wrote: post #58

Earlier quoted context omitted.

Using the non-aliased verbose form of the cmdlets: $hosts = 'host1','host2','host3' $source = '\\host0\c$\source' $dest = 'c:\dest' $executable = 'C:\Program Files (x86)\Notepad++\notepad++.exe' Invoke-Command -Computer $hosts -ScriptBlock { Get-Process | Where-Object Path -eq $using:executable | Stop-Process -Force Copy-Item -Path $using:source -Destination $using:dest } Explanation: Line 1-4: Set up variables to ma…

hey, this was a pretty good try! But here's what else you need to do: https://rkeithhill.wordpress.com/2009/05/02/powershell-v2-re... and if that's not hair-raisingly terrifying enough (note the super-intuitive 'set-item wsman://...' call), you'll quickly find that when you start a program (which you left off) using a script remotely, it doesn't show up anywhere on-screen, despite being authenticated as the logged-in…

> hey, this was a pretty good try! But here's what else you need to do:

No I don't. To open up a machine for remote administration, all I have to do is run Enable-PSRemoting like so:

    Enable-PSRemoting -Force
For domain-joined machines the authentication from there is just automatic, -i.e. when I use Invoke-Command it automatically created an authenticated and encrypted connection for the duration of the script execution.

> you'll quickly find that when you start a program (which you left off) using a script remotely, it doesn't show up anywhere on-screen, despite being authenticated as the logged-in user, but it does show up in the process list. Guess why THAT is.

That has nothing to do with PowerShell and everything to do with your expectation that you have equally poor session separation as with your typical nix.

With sufficient rights you can of course stop any process. But to reach in and control another user session is something else.

On Windows, processes are separated not just by the account they run under, but also by the session* under which they are created. Security barriers prevents a process in one session from interacting with processes in another session, even if they run as the same user.

This security boundary was raised to prevent compromised user processes from reaching into services and vice versa. This is part of the protection against shatter attacks and more.

I know a utility like psexec (sysinternals) may be able to launch a process in a foreign session, but I'm honestly not sure how it achieves this without some kernel support.

> but it does show up in the process list. Guess why THAT is.

That is because when you launch a process is launches in your session. A session is associated with a Windows Desktop (an operating system object type) which is a namespace separation somewhat like cnames in Linux. Windows on your (remote) session lives on the non-visible desktop associated with that session. When you log off it destroys the session and any processes running under the session.

You may not agree with the extra security features built into Windows, but the separation they create has noting to do with PowerShell.

Post reply on HN