Live data from Hacker News

Ask HN: Let's build Checkstyle for Bash?

news.ycombinator.com

41–50 of 71 posts

Re: Ask HN: Let's build Checkstyle for Bash?

#41
post #37

Earlier quoted context omitted.

Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?

What Python is to Java, Bash is to Python. Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu. I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.

I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha

rudimentary bash-fu

I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.

Re: Ask HN: Let's build Checkstyle for Bash?

#42

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a bet…

Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?

When you start to need error handling.

Re: Ask HN: Let's build Checkstyle for Bash?

#43
post #2

Out of pure curiosity, in what context do you write sufficient amounts of Bash scripts that style checking is a worry that needs your attention? While I also write small one-offs or bootstrap scripts here and there, in most cases it's my experience that developers opt for other languages for anything beyond small snippets.

What do you use the; if you want: - Self contained in one file - Easily edited with vi/nano (i.e. through a console ssh session) - Readily available on most Linux base installations - No crazy runtime installation requirements Edit: formatting)

If it is for myself: murex (my own DevOps focused shell: https://murex.rocks)

If it is for work: either Bash or whatever that companies preferred software development language (over the last ~20 years that's included: Pascal, Visual Basic, PL/SQL, Perl, PHP, Python, Typescript and others I've likely forgotten. Different companies will have different preferences)

If performance matters then these days Go is my "goto" language because it's a good compromise in terms of developer productivity and application performance. But I've used Java, C and C++ too. Depending on the particular problem I'm trying to solve.

...and if you ask me again in 5 years then the answer will be completely different again.

The sort answer is: there's no such thing as a single answer. Everyone will have their own preferences and business requirements.

Re: Ask HN: Let's build Checkstyle for Bash?

#44

Earlier quoted context omitted.

So your 10 lines of bash use a bunch of other programs to do almost all the work, right? So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.

Not even a bunch. It's calling a scraper written in Python, date to add some timestamps, git to add new db entries and push to version control, and touch to reload the webapp. All that in... (goes off to wc -l the script) ...twenty lines of bash, a third of which are comments. > language that lets you concisely express ways of calling out to other programs Seems like bash meets those requirements to me, dawg. /shrug

... but you cut off the word "good"... :-)

Re: Ask HN: Let's build Checkstyle for Bash?

#45

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a bet…

Seconded. I use Python daily and bash monthly at best. After the Nth time looking up how to do specific kind of conditional check in bash, I gave up started writing all the extra scripts and tooling I need using Python instead.

Re: Ask HN: Let's build Checkstyle for Bash?

#46

Earlier quoted context omitted.

Not even a bunch. It's calling a scraper written in Python, date to add some timestamps, git to add new db entries and push to version control, and touch to reload the webapp. All that in... (goes off to wc -l the script) ...twenty lines of bash, a third of which are comments. > language that lets you concisely express ways of calling out to other programs Seems like bash meets those requirements to me, dawg. /shrug

... but you cut off the word "good"... :-)

"Good enough" is good in my book, and bash is good enough for me.

Still wish someone would give me an idea of what "large" means in bash scripts.

Re: Ask HN: Let's build Checkstyle for Bash?

#47

Earlier quoted context omitted.

Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?

When you start to need error handling.

...unix return codes?

Sorry even I can't say that with a straight face XD

Re: Ask HN: Let's build Checkstyle for Bash?

#48

Earlier quoted context omitted.

What do you use the; if you want: - Self contained in one file - Easily edited with vi/nano (i.e. through a console ssh session) - Readily available on most Linux base installations - No crazy runtime installation requirements Edit: formatting)

python.

Which python? 2.7 that is symlinked to `python` on the distro? 3.5 that is installed by default? or perhaps you meant 3.9 but what about that cool library that you're gonna use which is only available for 3.9.2 and not 3.9.1 due to a bug?

How are you gonna handle installing that beautifulsoup dependency in a way that does not bork the OS python deps?

Are you gonna use `python -m venv` or `poetry` or `pipenv`?

Re: Ask HN: Let's build Checkstyle for Bash?

#49
post #37

Earlier quoted context omitted.

What Python is to Java, Bash is to Python. Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu. I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.

I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha rudimentary bash-fu I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.

You might want to check out 'hck' to replace 'cut'.

https://github.com/sstadick/hck

Re: Ask HN: Let's build Checkstyle for Bash?

#50
post #49

Earlier quoted context omitted.

I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha rudimentary bash-fu I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.

You might want to check out 'hck' to replace 'cut'. https://github.com/sstadick/hck

I may give it a try - I have a bias to stuff that comes preinstalled, though, as I know I'll always have the chance to use it on a stock linux box.
Post reply on HN