He was running it by invoking it If you run it, invoking as bash, as you had intended, the script completes fine. There are no errors about parens.

1 members found this post helpful.

Would you please clarify precisely what you mean by "invoking as BASH"?

Ah yes. I think they might mean the 'sh' shell.

UPDATE -----

Script has been rewritten to the POSIX standards

Strict(er) POSIX compliance when invoked as 'sh'. No bash specific features.

https://www.gnu.org/software/bash/ma...ash-POSIX-Mode

1 members found this post helpful.

OR we can convert it to POSIX compliant as suggested.


UPDATE -----

Script has been rewritten to the POSIX standards

(Grin) More homework, eh?

I made the script executable (chmod +x) on my Debian machine and it ran correctly. I'll look forward to reading up tomorrow about why that was. In any event, it might be wise to anticipate that others might also be unaware of this, especially the target audience (as we would say in the training biz) for this script.

This is something I've not run into before. Thanks to both of you.

Afterthought:

So using sh to run a script specifically invokes the shell shell, as opposed to any other shell?

Looks like one way to check for POSIX compliance is to use a tool called 'shellchecker' that I found here: https://github.com/koalaman/shellcheck

Using this against the script should let us know if we are using any non-posix shell scripting and allow us to rewrite it ahead of time.

UPDATE -----

Script has been rewritten to the POSIX standards

HA. Not at all. Just figured that page could explain it better than I could.

In short, if you invoke bash using 'sh', either by
or bash will run in a stricter POSIX compliant mode, as the original bourne shell would have. So a lot of stuff we expect to work, will not, because they are actually bash specific.

Invoking bash as itself

or will allow a script to use those bash specific builtins and syntax.

There seem to be a few things (myself included) do when we write shell scripts that are bash specific, but don't realize it until cases like this. Some are obvious, some documented better than others.

As an aside, there's still the nagging question as to why

worked in CentOS and Slackware and not in Debian and Mint.

sh can be a symlink back to bash or dash.

Debian and derivatives use dash as the default shell. Although I haven't looked into it, perhaps that explains the discrepancy.

I'd be interested in collaborating.

1. Shouldn't we 'represent' LQ with lqdebug and not ldebug?
2. output to a pastebin-like URI?

Seems the poor dears can't find the code boxen to save their lives. Bless their hearts.

More than enough diverse hosts to run any script against.

Subscribed with interest...

1 members found this post helpful.

Good points. I would not name it lqdebug without the blessing of Jeremy. So to keep it general and without official ties to LQ I think it should stay 'ldebug'.. That was my thought.

Changed the pastebin line to be more general.

Would love to have you collaborate. Just fork and pull request any changes/additions you would like. Thanks for your input.

One thing I was thinking of was allowing auto-pasting to the related LQ thread number as a 'ldebug output reply' or something. I could do that real simple like if there were an API, but my username/password + curl request is a bit rusty to do so. Seem like something you could shine light on?

heres my attempt:
http://www.linuxquestions.org/questi...ng-4175509407/

inxi mite make this redundant ?

1 members found this post helpful.

It's just a pet project. Everything has been done before. Bashtool, ohai etc... But i'm trying to keep ldebug wayyyyyyyyyyyyyyy smaller than 15000 lines and easy to read and understand.

Most likely it will disappear into obscurity or never be used by anyone but myself,.. but until then it's hopefully a nice way to collaborate and talk with other interested LQ members. It's nice to be a part of making something useful. And it's in bash - so no one has to take hours out of their day to debug and contribute. Someone can just add a good command and call it a day. Or make a suggestion. That sort of thing.

3 members found this post helpful.