Shfmt – format shell programs (like gofmt, rustfmt)

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • sh

    A shell parser, formatter, and interpreter with bash support; includes shfmt (by mvdan)

  • For the first two caveats, I actually agree that we could and should handle ambiguous input. It just hasn't been a priority because doing that properly would be quite a bit of work, and such ambiguous syntax isn't particularly common. See https://github.com/mvdan/sh/issues/686 for my current thoughts on how to tackle it.

    The third caveat concerns parsing `export` and `let` as keywords rather than as builtins. Like the README says, this is to properly build the syntax without leaving opaque strings as expressions, but also to support `declare foo=(bar)` which wouldn't work if `declare` was treated like any other builtin simple command.

    How else would you have a static parser handle these two builtins? They are in a bit of an awkward middle ground between builtin and keyword. My instinct is that giving them special treatment in the parser to allow tokens like `(`, while at the same time representing them in the syntax tree with opaque strings as expressions, would be pretty underwhelming to any users of the parser.

    That said, we already have that problem with `let "foo=123"` for example, where our parser currently represents the expression as the quoted string without going any deeper. https://github.com/mvdan/sh/issues/754#issuecomment-96329574... considers doing a second parse stage in the shell interpreter to fix cases like these, though always doing a second parse could get expensive.

    We _could_ leave all arithmetic expressions as input strings in the parser, and do all the actual parsing when they are evaluated. That would be more compatible with Bash and more consistent. But it would also be less useful to any parser users who don't run into any of these weird edge cases, which aren't common at all, I think.

    In short, I have some ideas, but I'm not sure at all what's best :) Doing a good job for 99% of users feels better than aiming for 100% compatibility with bash syntax, particularly where bash syntax is a bit weird.

  • ShellCheck

    ShellCheck, a static analysis tool for shell scripts

  • I throw all my shell scripts through this beast of a haskell application to see if they're clean:

    https://github.com/koalaman/shellcheck

    Crucially it shows where on the line the error is in case I've got some large piped one-liner which might have a problem.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • First Bash Script

    2 projects | /r/bash | 23 Sep 2021
  • Linux Minecraft Server built - Cheapo mode + rsync backup

    2 projects | /r/admincraft | 12 May 2021
  • Code formatter, linters, etc. Recommendations?

    4 projects | /r/bash | 29 Sep 2021
  • How to get diagnostics in BASH scripts (.sh files) with Native LSP?

    4 projects | /r/neovim | 17 May 2021
  • Bash-LSP: A language server for Bash

    6 projects | news.ycombinator.com | 1 Apr 2021