ShellCheck is a static analysis tool for bash/sh scripts - try it on your scripts. The README also shows some examples of what (not) to do.
The link to your project gives me a 404 btw, is it a private repository?
ShellCheck is a static analysis tool for bash/sh scripts - try it on your scripts. The README also shows some examples of what (not) to do.
The link to your project gives me a 404 btw, is it a private repository?
You don't need a plugin, just use the bash LSP server with any editor that support LSP servers. It supports explainshell, shellcheck and shfmt.
"Just", lol. I'm sure yours is a much more comprehensive and powerful solution, but it definitely looks more complex than just installing a plugin on your IDE!
Is pluging a LSP server that hard on vscode/intellij? Because it's automatic with a lot of LSP clients, open a .sh
file, get asked if you want to install the corresponding LSP server, answer yes and that's it. Some LSP clients don't do automatic server install but you just have to install the server with your packet manager. At least that's how it is with vim / emacs.
No idea, I'd never even heard of one until your comment! Is it worth setting up? What else does it do?
Funny thing is that LSP was actually created for VSCode. That's the now standard protocol to decouple language specific things (completion, formatting, linting…) from the editor so you don't have to use an editor for each language. You can now use any editor that supports LSP, either directly or through a plugin, and turn it into a fully fledged IDE by installing the LSP servers for the language you need. I guess some VSCode plugins use LSP under the hood and just embed the server.
I love ShellCheck! It's one of the biggest FOSS projects written in Haskell.
Thanks. I checked it out. It'd be cool if they have LSP setup.
And thanks for informing about the link, I made a typo :]
But it is written in haskell, unpractical language
Well Why do I love trolling this much..
Don't know about everyone else, but here are some of mine:
Only thing to disagree here is 80 char limit, would go for 120 personally.
Also, IMHO, pipes should be at the beginning of the next line, not at the end of the previous one.
Makes cleaner commits and nicer diffs.
A post to save ❤️
This guy scripts
I once did a sh script that needed (because I wanted a challenge?) to be compatible with vanilla Android shell too. So I needed to test it with regular bash, busybox and mksh+toybox. That was 'fun'.
I've had some initial plans to spllit the code out from that project and develop a "shell" library that would ease building shell scripts that are compatible with different systems... But I bet someone else has already done that.
$() instead of
So much this!
A yes, the fear of opensourcing.
Trust me, proprietary code is often total garbage because nobody looks at it.
There is no single Bash standard to follow, only a few guidelines. One way you can check for some basic errors and formatting would be using an editor with support for Bash (in best case with a builtin LSP). At the end, you have to find your style and coding standards or adapt what others do if you want work with them or edit their files.
${variable}
and some other things.BTW the mk-blog link is 404 for me.
Yeah I came across that google's guide, but I skipped it when I found out its from google. And thanks for informing about the link, I made a typo
If your bash script gets longer than 200 lines (including argument handling), use Python. I have to support bash APPLICATIONS at work and it's a fucking nightmare to maintain.
I would then assume those scripts weren't written properly to begin with.
But yes, shell scripts should be used (normally) to automate some simple tasks (file copying, backups...) or as an wrapper to exec some other program. I've written several shell scripts to automate things on my personal machines.
However shell script can be complex program while at the same time being (somewhat) easy to maintain:
This way at least I don't break my scripts, when I need to modify a function or some way extend my scripts. Keeping the UNIX philosophy inside shell scripts: let one function do one thing well.
And of course: YMMV. People have wastly different coding standards when it comes to personal little(?) projects.
How do you unit test something like that?
I had several tests at the beginning of the script. These tests define the "low-level" functions based the capability of the shell. To test new features I "simply" ran all the necessary commands on the test environments (bash, busybox, toybox+mksh).
The script would error out if some necessary capability was missing from the host system. It also had a feature to switch shell if it found a better one (preferring busybox and its internal tools).
Yeah... It was tedious process. It was one of those "I'll write a simple script. So simple that it'll work on almost every posixy shell."... rest is history.
I haven't used it on a project for money, but I have some tests in shunit2 and that alone encourages me to extract code to functions.
I try to follow Bash strict mode. It can protect you from some foot shooting.
Not what Im asking for, but this is awesome!
https://github.com/bash-lsp/bash-language-server
Yeah, I have bash ls installed, but it wont teach me coding standards right
Bash LSP server can use shellcheck and shfmt but you have to install those manually.
Choose whatever fits you
And stick to it! Also make sure other participants also adhere to that. Optionally configure a linter for doing that.
Thanks
Repos are archived by the maintainer, but I find these really helpful resources:
https://github.com/dylanaraps/pure-bash-bible https://github.com/dylanaraps/pure-sh-bible
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0