10

What the absolute fuck is this!
Fucking bash needs to get its shit together with its fucking strings.
I don't fucking know why str1 + var2 = var2tr1
Like who designed this fucking bullshit!

I've spent the past 8 hours today counting all my ' and " and making sure everything is getting passed correctly.

And how do you even google this shit anyways!

And why the fuck is the official suggestion from the bash FAQ to load everything into an array and to call it with "${ARRAY[@]}"

WHO THE FUCK DECIDED THAT WAS READABLE!!

AUGH!!!

In case anyone was wondering. It didn't work anyways.

I think I'm done for today... I can't anymore...

for anyone wondering. This is bash getting executed by nodejs with execSync()
and those tokens are temporary and only exist on my dev machine. Sorry for getting your hopes up.

Comments
  • 7
    Perhaps try go or python
  • 2
    @alexbrooklyn wish I had been on this team sooner to make that decision
  • 4
    Shellscripts are unreadable anyway, the syntax is inconsistent and unintuitive.

    Ok, most of it originates from 1856 or maybe already 1789, but I don't understand why it hasn't evolved to something read- and usable over the last 2 decades.

    If possible, I would try to switch to python or some other scripting language with usable syntax.
  • 1
    The output looks like you have a \r somewhere.
  • 1
    relax, it could have been PHP
  • 3
    <language I don't know well> is unreadable and illogical!

    Yeah, yeah, yeah. We've heard this rant in 100 different flavors over the years. Shell is my bread and butter right now so I have no sympathy for you not understanding how it works.

    Just look at all the "WTF JavaScript" rants on here...

    And, while I agree that badly written shell can be unreadable, so can badly written <insert language here>.

    So, yeah, no sympathy from here.
  • 3
    @JustThat Yes, sure, 'if [ -z "$var" ]' is readable AF. Really intuitive.

    How many here know what that does without looking it up?
  • 0
    @ddephor it's a condition ! I think/hope
  • 1
    @JustThat TBH I'm more frustrated with how complicated strings are in bash. I just learned that ' " and ${} all represents strings but in different ways
    ' being a string literal
    " being a format string
    ${} being a format string with slightly different escape characters than "

    And right now I may have one of these in my string and can't easily figure out with an echo if there is one in it.
  • 1
    Who the fuck uses dots in bash variable names and then complains about undef behaviour?

    Which experimental bash option have you set to even allow this kind of fuckery..???
  • 2
    If these are not bash vars I see in the shot [why tf would you show them then?!?], sanitize your fucking output by removing your fucking carriage fucking windows' returns!

    Fuck! Idk why I am swearing. Guess I've caught cold. And maybe the fact that I was nearly killed twice today in Latvia. FUCK!!

    FUCK!!

    P.S. If you're aiming to your foot and pulling the trigger then do not blaim the shotgun
  • 0
    @andpeterson Yeah, I've been bitten by using the wrong encapsulation on a variable multiple times. But coding standards and familiarity helps with that.

    Just as with any other language.

    Put me in js for a month and I'd likely be ranting about things that seasoned js coders would be laughing at, too.
  • 0
    @ddephor I'm on that list. But, as I've said, this is what I spend 75% of my time doing right now.

    -z = is zero length
    -n = is non-zero length

    For a quick rundown on the options try the ultimate masculinity command:

    man test

    Of course, that doesn't include wonders like:

    -n doesn't work with unquoted arguments so you have to quote it or use double-brackets
  • 1
    @JustThat just doublequote your variables everywhere and you'll prevent 98% of undef behavior
Add Comment