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

61–70 of 80 posts

Re: Stronger Shell

#61

Post by warfangle »

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…

While likely to work (I don't use powershell), I think you missed the main constraint posed: kill a running GUI with a certain name.

Your solution finds the process to kill only if the executable path is at a known location.

How would you do this if you only know what the process name will be -- e.g., what if the executable path is on D:\stuff\gui.exe on host1 and E:\secretstuff\gui.exe on host2, if gui.exe always runs as a process named "Updatable GUI Thing"?

Re: Stronger Shell

#62

Post by barrkel »

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…

I've written some in the 200-300 line range, that took 500+ lines of Ruby to replace. Ruby was less efficient in wall-clock time, but easier to scale up in features. It required using a database for storage rather than line-oriented text files (the problem set was too large to fit in-memory as Ruby objects at least) - a source of performance loss, as I went with sqlite to keep things self-contained. I could have coded in a pipe / batch oriented way like bash, but then I wouldn't have gained any ease of feature implementation.

If you can express a problem as a set of filters and pipes, don't need to fork too much, and have efficient executables to run each stage of the pipe, bash can be hard to beat without breaking out a real programming language with threading support. That's because bash isn't doing the heavy lifting, just doing process orchestration - something it does better than any scripting language I've used. <() in particular is tedious to do in most non-shells (and many alleged shells).

Re: Stronger Shell

#63

Post by CJefferson »

One this which greatly helped me was understanding that [ is a program, like any other, which takes arguments. It's a small thing, but made the shall less magic.

Re: Stronger Shell

#64

Post by baghira »

StavrosK wrote: post #47
heydonovan wrote: post #29

Just about everything I've learned about bash has been from the #bash IRC channel on Freenode. You'll see the same repeated warnings of not learning from the public web, due to the fact that misinformation spreads like a wild fire, and some articles out there are just flat out wrong (sort of like w3schools in the #css circle). There is just one thing I will never understand. The tired argument of "...but it isn't por…

Seconded. I can't live without fish, and I hear this "but what about my bash scripts?!" argument a lot. Unless you're actually sourcing the script, it has a magic "#!/bin/bash" line on top that makes it work correctly!

It's not that simple. Changes in the syntax for strings and environmental variables are going to bite precisely newcomers who would benefit the most from fish. And sourcing happens.

I do know that all these problems result from fish having a saner syntax compared to bash (hell, FWIW I'm still mad that globs are not regular expressions and have a different syntax) but everytime someone points out these problems the reaction is "#!/bin/bash", which kinda misses the point.

Re: Stronger Shell

#65

Post by agumonkey »

realharo wrote: post #6

I personally can't stand bash for writing scripts (it's fine for typing one-liners into terminal though). This question and its top answer capture the insanity of bash quite nicely http://stackoverflow.com/questions/3601515/how-to-check-if-a... .

Following the trends of transpiling modern linguistic ideas to lower languages (see all the xyz -> js), I asked why it wasn't the case, someone told me it "was", it's called awk.

Re: Stronger Shell

#66

Post by useerup »

warfangle wrote: post #61
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…

While likely to work (I don't use powershell), I think you missed the main constraint posed: kill a running GUI with a certain name. Your solution finds the process to kill only if the executable path is at a known location. How would you do this if you only know what the process name will be -- e.g., what if the executable path is on D:\stuff\gui.exe on host1 and E:\secretstuff\gui.exe on host2, if gui.exe always ru…

Silly me, I assumed that the executable path was the requirement. My bad. If you need to find a process just by it's name, it is even simpler: Just indicate the process name (possibly with wildcards) to Get-Process (alias ps):

ps Notepad++ | kill

Actually, kill (alias for Stop-Process) takes a name parameter directly, so the "kill" line from the script could be written as simply

kill notepad++

But your question is actually really good, because what if we did not know the neither the process name nor the executable, but -say- only the Window title? Get-process (alias ps) will produce a sequence objects describing the running processes. If I want to know what properties those objects have that I can possibly filter on, I can pipe the objects through the Get-Member cmdlet (alias gm):

    ps | gm
This produces a table-formatted list like this (shortened):

    TypeName: System.Diagnostics.Process

    Name                       MemberType     Definition
    ----                       ----------     ----------
    Handles                    AliasProperty  Handles = Handlecount
    Name                       AliasProperty  Name = ProcessName
	...
    MainModule                 Property       System.Diagnostics.ProcessModule MainModule {get;}
    MainWindowHandle           Property       System.IntPtr MainWindowHandle {get;}
    MainWindowTitle            Property       string MainWindowTitle {get;}
    MaxWorkingSet              Property       System.IntPtr MaxWorkingSet {get;set;}
	...
    Site                       Property       System.ComponentModel.ISite Site {get;set;}
    StandardError              Property       System.IO.StreamReader StandardError {get;}
    StandardInput              Property       System.IO.StreamWriter StandardInput {get;}
    StandardOutput             Property       System.IO.StreamReader StandardOutput {get;}
    StartInfo                  Property       System.Diagnostics.ProcessStartInfo StartInfo {get;set;}
	...
    Product                    ScriptProperty System.Object Product {get=$this.Mainmodule.FileVersionInfo.ProductName;}
    ProductVersion             ScriptProperty System.Object ProductVersion {get=$this.Mainmodule.FileVersionInfo.ProductVersion;}
Lo and behold, there is a property called MainWindowTitle. So to stop a process by it's main window title I could write:

    ps | ? MainWindowTitle -eq 'Deepthought Main Console' | kill
That is, find all processes, pipe them through a filter selecting only those where the MainWindowTitle equals the desired text, and pipe those processes to the Stop-Process cmdlet

Re: Stronger Shell

#67

Post by agumonkey »

david-given wrote: post #8
realharo wrote: post #6

I personally can't stand bash for writing scripts (it's fine for typing one-liners into terminal though). This question and its top answer capture the insanity of bash quite nicely http://stackoverflow.com/questions/3601515/how-to-check-if-a... .

Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern…

Imagine what if this one had been standard https://wryun.github.io/es-shell/manpage.html

Re: Stronger Shell

#68

Post by qznc »

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.

Re: Stronger Shell

#69

Post by gtk40 »

crimsonalucard wrote: post #21

interviewers tend not to test for shell skill even though your shell skills are usually more relevant to daily tasks. I'm debating whether to improve on my shell skills or algorithm skills.

My interview for the job I have now actually had me do some hands-on shell activities and had very little algorithms, but that was partly because they were wanting me to work with code deployment and other tasks where it would come in handy.
Post reply on HN