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

Bash Pitfalls

bash.cumulonim.biz

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Bash Pitfalls

#41

Post by gwu78 »

comex wrote: post #34
sigil wrote: post #32

Earlier quoted context omitted.

> Every single one of these questions is easier to answer if you're using a less agonizing language than Bash and its relatives. I disagree. While the set of things that are "hard" to do is probably larger in shell than the alternatives, the specific questions posed by the grandparent are hard in any language. They all boil down to "how can I correctly do something which has side effects (on external state)?" Statefu…

> tr '[A-Z]' '[a-z]' lower.txt That's the biggest problem: some things are very simple, but other things fall off a cliff. For example, as a related task I ran into recently: how do you replace FOO with the contents of foo.txt? The natural way would be expanding it into a command line, but at least with sed that's no good even for nice short text files because / and \n are special. You can use a sed command to read a…

You can use cpp.

As for "capture groups", you can use lex. I wrote a "code generator" shell script to produce .l files and another script that compiles .l files to one-off utilities.

There is perhaps more coherence to the whole thing than you are aware of. Whether "Linux distros" or "OSX" have maintained that coherency I do not know.

Re: Bash Pitfalls

#42

Post by jjwiseman »

clarry wrote: post #21
Sivart13 wrote: post #5

Earlier quoted context omitted.

Seriously? They can't find a better place to host a site like this here in 2013?

If you already have a machine serving stuff at home, adding a remote server is only time, money, and effort spent. Is it worth it? Not all sites are high in volume, and even well prepared sites on decent lines can go down if it hits the HN front page. People do occasionally bitch and moan about slow downloads from my home host, but nobody ever offered money for a pain-free alternative.

Google doc, gist, tumblr, any free blog engine.

Re: Bash Pitfalls

#43

Post by a3_nm »

comex wrote: post #34
sigil wrote: post #32

Earlier quoted context omitted.

> Every single one of these questions is easier to answer if you're using a less agonizing language than Bash and its relatives. I disagree. While the set of things that are "hard" to do is probably larger in shell than the alternatives, the specific questions posed by the grandparent are hard in any language. They all boil down to "how can I correctly do something which has side effects (on external state)?" Statefu…

> tr '[A-Z]' '[a-z]' lower.txt That's the biggest problem: some things are very simple, but other things fall off a cliff. For example, as a related task I ran into recently: how do you replace FOO with the contents of foo.txt? The natural way would be expanding it into a command line, but at least with sed that's no good even for nice short text files because / and \n are special. You can use a sed command to read a…

You can use sed's external command mechanism to do that. This replaces lines of the form "include foo.txt" with the contents of foo.txt.

    sed 's/^include \(.*\)/cat "\1"/e'

Re: Bash Pitfalls

#44

Post by ygra »

comex wrote: post #7

The Unix shell may be a highly powerful interactive programming environment, but it's sure hard to think of anything that comes anywhere close to sucking as badly. With the shell and the standard Unix commands, some things that are hard in other languages are easy, and most of the things that are easy in other languages are hard to impossible... I'd love to see a clean slate replacement for the shell that still feels…

PowerShell is nice and in principle seems more Unixy than the normal Unix core utils in that cmdlets really do only one thing and that one well (most of ls' options for example can be solved by simply combining Get-ChildItem with Sort-Object or one of the Format-* cmdlets).

As for a port, you're welcome to contribute on Pash (https://github.com/Pash-Project/Pash) – it's still woefully incomplete, sadly.

Re: Bash Pitfalls

#45

Post by ygra »

derefr wrote: post #38
anon4 wrote: post #33

I know someone will sooner or later propose that we ban spaces and special characters in names. Let me just put my two cents forward. We should absolutely ban special characters from names. Specifically, all whitespace, the colon, semicolon, forward slash, backward slash, question mark, star, ampersand, and whatever else I'm missing that will confuse the shell. Also files cannot start with a dash. However, people sho…

> Substitute each problematic byte with equivalent percent-encoded form. This does not touch bytes over 0x80 - they are assumed non-problematic. You know what's crazy? Currently, in Unix, control characters are allowed in filenames. Like, \t and \n and \b and even \[. Those shouldn't be allowed, percent-escaped or not. Everything else you said is sensible.

Technically NTFS allows those too. The filesystem, being a very low-level tool, hardly thinks of the upper layers and what pain it might inflict there. Its purpose is to store blobs under a name and retrieve them upon request. Since a char[] (or wchar_t[]) looks enough like a name that's what it uses.

That being said, enforcing such restrictions in upper layers brings pain as well, because suddenly you can have files that you cannot delete anymore (happens sometimes on Windows).

Re: Bash Pitfalls

#46

Post by zwp »

dj-wonk wrote: post #17

Would someone recommend an automatic bash style checker, such as a 'linter'? Perhaps something along the lines of Chef's Food Critic? http://acrmp.github.io/foodcritic/

Shellcheck recently found a bug in one of my old scripts. You can use the web interface or compile it for local use:

http://www.shellcheck.net/

https://github.com/koalaman/shellcheck

Re: Bash Pitfalls

#47

Post by clarry »

jjwiseman wrote: post #42
clarry wrote: post #21

Earlier quoted context omitted.

If you already have a machine serving stuff at home, adding a remote server is only time, money, and effort spent. Is it worth it? Not all sites are high in volume, and even well prepared sites on decent lines can go down if it hits the HN front page. People do occasionally bitch and moan about slow downloads from my home host, but nobody ever offered money for a pain-free alternative.

Google doc, gist, tumblr, any free blog engine.

None of which are pain-free to me.

Re: Bash Pitfalls

#48

Post by comex »

a3_nm wrote: post #43
comex wrote: post #34

Earlier quoted context omitted.

> tr '[A-Z]' '[a-z]' lower.txt That's the biggest problem: some things are very simple, but other things fall off a cliff. For example, as a related task I ran into recently: how do you replace FOO with the contents of foo.txt? The natural way would be expanding it into a command line, but at least with sed that's no good even for nice short text files because / and \n are special. You can use a sed command to read a…

You can use sed's external command mechanism to do that. This replaces lines of the form "include foo.txt" with the contents of foo.txt. sed 's/^include \(.*\)/cat "\1"/e'

Sounds useful, but it's not portable, and doesn't work on OS X. I suppose I could just switch to GNU sed, since I mostly care about interactive use, but thus far I haven't done so.

Re: Bash Pitfalls

#49

Post by Dylan16807 »

clarry wrote: post #47
jjwiseman wrote: post #42

Earlier quoted context omitted.

Google doc, gist, tumblr, any free blog engine.

None of which are pain-free to me.

Dropbox? Unless you're pushing gigabytes per day it should make a perfect static host with urls no more ugly than previously mentioned services.

Re: Bash Pitfalls

#50

Post by nfoz »

comex wrote: post #7

The Unix shell may be a highly powerful interactive programming environment, but it's sure hard to think of anything that comes anywhere close to sucking as badly. With the shell and the standard Unix commands, some things that are hard in other languages are easy, and most of the things that are easy in other languages are hard to impossible... I'd love to see a clean slate replacement for the shell that still feels…

> I'd love to see a clean slate replacement for the shell that still feels Unix-like and retains most of its existing benefits.

I've been working on one, in my spare time for about a year. I can't tell you how exciting it is. It's still a ways from being ready for actual use, but I'll have a website up in a couple of weeks to showcase the approach, and will surely post to HN when it's up.

Post reply on HN