Live data from Hacker News

My deployment platform is a shell script

j3s.sh

101–110 of 141 posts

Re: My deployment platform is a shell script

#101
post #62

Earlier quoted context omitted.

I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.

I would RTFM so I actually learn something instead of using """AI""" regurgitation.

I find the manual for bash to be a terrible way to learn things

Re: My deployment platform is a shell script

#102
post #33

The use of ls in this way is not good form: cd /root for project in $(ls go-cicd); I think a better expression would be: for project in ./* do [ -d "$project" ] || continue ...

Some other nit-picks about this script.

- Everything here is done as root. For the day that you want to build with lesser privilege, do this:

  BLDUSER=~root
- That will be difficult for you, because you are moving the projects to /usr/local/bin; for the day that you stop running as root, make a subdirectory "/usr/local/bin/$BLDUSER" (owned by the namesake account) and move the projects there instead.

- Very minor nitpick, use - Slight improvement, so this can print more than one argument:

  println() { y=
    for x
    do printf %s%s "$y" "$x"
       y=' '
    done >> /root/gocicd.log
    echo >> /root/gocicd.log # for the newline
  }

Re: My deployment platform is a shell script

#105

If the author is reading this: did you code the fish animation CSS manually or used some wrapper for all these moz- and webkit- variants?

It’s a fish? I thought it was a pocket watch

Well, that would make it quite an exotic watch: https://j3s.sh/static/unnamed-puffy.png

Re: My deployment platform is a shell script

#107

I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liabil…

[flagged]

> nobody wants to maintain your mess of shell scripts.

Have you seen the scripts in question? Are you in any kind of way able to make such a value judgement over this persons work? Have you considered the impact of your choice of words on others?

Re: My deployment platform is a shell script

#108

Earlier quoted context omitted.

When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant. Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh

I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.

It’s not everywhere though, FreeBSD for example doesn’t use it.

Re: My deployment platform is a shell script

#109

Earlier quoted context omitted.

It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward. Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked…

Shell seems great until your tens of lines in googling every other line of obscure error-prone syntax.

… or maybe you are not proficient at shell scripting? I never had this issue, including large projects written in tcl, bash or perl in the 90s when it was more normal to do so.

The modern answer seems to be some kind of dsl with yaml syntax mixed with Unix (and thus bash) snippets which are often incredibly verbose and definitely not easier to read than a well written bash script. The only thing I think of when I see those great solutions is; another greenspun’s tenth rule in action.

Re: My deployment platform is a shell script

#110

Earlier quoted context omitted.

Shell seems great until your tens of lines in googling every other line of obscure error-prone syntax.

… or maybe you are not proficient at shell scripting? I never had this issue, including large projects written in tcl, bash or perl in the 90s when it was more normal to do so. The modern answer seems to be some kind of dsl with yaml syntax mixed with Unix (and thus bash) snippets which are often incredibly verbose and definitely not easier to read than a well written bash script. The only thing I think of when I see…

bash and other sh related approaches have a lot of "foot guns". python, or powershell, or even C++ are often easier to read and follow.

> are often incredibly verbose and definitely not easier to read than a well written bash script

define well written -- getting into no true scotsman here.

bash is fine for what it was and what it did, and i'm glad to know enough sed and awk to be dangerous, but it's a PITA unless we're forced to use it

Post reply on HN