0

I am using Ubuntu 14 /bin/bash. The shell script does not fail, if a certain function is not found. How can I make the script exit if something like this happens?

For reference my code structure at the high level is:

funcA() {
   funcB() # this is accidentally called but is never define due to editing error
   funcC()
}

funcA
itzFlubby
  • 2,269
  • 1
  • 9
  • 31
drdot
  • 3,215
  • 9
  • 46
  • 81
  • Just use the **exit** statement to exit your program. – itzFlubby Dec 07 '18 at 22:49
  • [BashFAQ #105](http://mywiki.wooledge.org/BashFAQ/105#Exercises) is worth reviewing, to understand the limitations and pitfalls of any kind of automated error-handling behavior in bash. (My general advice is that the facilities in question are so unreliable one is better off without them, relying on static checking, code review, and manual error handling instead). – Charles Duffy Dec 07 '18 at 22:53
  • 1
    Note also that "any function is not found" is indistinguishable from "command is not found" -- the interpreter doesn't know if your command is supposed to be implemented by a function, vs supposed to be implemented by something on the PATH, vs supposed to be implemented in any other way. (The `funcB()` syntax here I'm assuming was a thinko, since functions are just called as `funcB` at invocation point). – Charles Duffy Dec 07 '18 at 22:55
  • Use bash's trap builtin to spawn a bash instance upon the script's exit: – wuseman Dec 08 '18 at 00:16
  • @CharlesDuffy I understand what you mean, but of course the interpreter must technically "know" whether the command is a function, etc. Not at the instant that it parses it from the script, of course. It has to check aliases, functions, executables in `PATH`, etc, to determine exactly what `funcB` refers to. Also, it is technically possible to query that in a script, e.g. `type -t funcB`, at least if OP doesn't mind using a bashism. That would of course be more trouble than it's worth. But that's different than "the interpreter doesn't know". – Mike Holt Dec 08 '18 at 01:21
  • That's a bug you should catch and fix during testing, not something to handle at run time. – chepner Dec 08 '18 at 03:03
  • @MikeHolt, ...it only knows that a command is provided by a function **when that function is defined**. But the case the OP here cares about is when something *isn't* defined, and in that case, there's no possible way to determine the type of a command that doesn't exist. – Charles Duffy Dec 08 '18 at 03:30
  • @CharlesDuffy OP is trying to determine *if* a command/function is defined, and `type -t funcB` would tell him that. From `help type`: `-t output a single word which is one of 'alias', 'keyword', 'function, 'builtin', 'file', or '', if NAME is an alias, shell, reserved word, shell function, shell builtin, disk file, or not found, respectively.` This is exactly what type is for. Again, from `help type`: `For each NAME, indicate how it would be interpreted if used as a command name.` This is exactly what OP seems to be asking for. – Mike Holt Dec 08 '18 at 03:42
  • `[[ -z "$(type -t funcB)" ]] && exit 1` – Mike Holt Dec 08 '18 at 03:43
  • Having said that, I agree with your statement that this is not something to handle at run time. Nonetheless, `type -t` *does* answer OP's question, our judgments about its practicality notwithstanding. – Mike Holt Dec 08 '18 at 03:47
  • @MikeHolt, ...eh? `type -t funcB` will **always** emit an empty string if `funcB` does not exist -- not `command` or `function`, so it can't distinguish between the types of things that don't exist. And the OP is explicitly asking to handle **only** the case of a *function* that doesn't exist, requiring that it be disambiguated from a *command* that doesn't exist... but things that don't exist don't have types at all, so `type -t` won't return anything useful about them. – Charles Duffy Dec 08 '18 at 15:17
  • @MikeHolt, ...`type -t funcB` will tell you if `funcB` doesn't exist *and a like-named command is found in its place*, sure, but that's not what I read this question as asking for -- they want to be able to configure the shell to trap "command not found" errors, and then automatically determine if the thing that's missing is a function or not. That's simply not possible -- if a command's not found, one can't tell if it's programmer error that the function intended to provide it isn't defined, or ops team error that the external program intended to provide it isn't found. – Charles Duffy Dec 08 '18 at 15:20
  • (Well, can't tell absent a list of expected function names, and if a programmer could maintain an accurate whitelist, they could probably also maintain an accurate set of function declarations -- you're just creating two places where mistakes can be made instead of one). – Charles Duffy Dec 08 '18 at 15:22
  • @CharlesDuffy I already said I agree it's a bad idea. The negative effect you're talking about is inherent in OP's question, not something I've brought into the situation with my `type -t` suggestion. – Mike Holt Dec 09 '18 at 16:23
  • @MikeHolt Thank you for the discussions and sorry for the late reply. I am ok not distinguishing the function and command not found. I think the type suggestion is fine except that i have to use type to check at the beginning of every function call which makes the code clumsy. The better route for me is to debug the code carefully and fixing the script – drdot Dec 10 '18 at 17:37
  • @CharlesDuffy Thank you. I can only tag one person at a time. See my comment above. – drdot Dec 10 '18 at 17:37
  • @drdot There are ways you could use `type` and mitigate the mess somewhat, but there's no need to elaborate since I think it's unnecessary at this point. – Mike Holt Dec 10 '18 at 18:28
  • @MikeHolt, yes. Thank you for the suggestion :) – drdot Dec 11 '18 at 03:07

0 Answers0