-1

It seems that my environment has changed such that if/else statements do not work. Typing this in the terminal:

if true; then echo 1; else echo 2; fi;

will wait for another token (with a > prompt), not executing as expected.

I've tried writing this statement in other bash environments, and it prints "1" to stdout, as expected. I have no idea what I did to make my if statements not work.

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
Cam Hashemi
  • 157
  • 1
  • 7
  • The code you posted works for me. It seems you're not showing us the whole code, which makes it impossible to help you. – Robert Oct 10 '16 at 23:03
  • Typing that command in my terminal does not work. The prompt waits for another character to be input. That said, it's not that my syntax is wrong, but that something has changed in my environment that makes the syntax wrong. Other bash syntax works, just if/else does not. Any idea why? – Cam Hashemi Oct 10 '16 at 23:06
  • what is the output of `type if` ?? –  Oct 10 '16 at 23:14
  • probably not bash... check your shell. – Karoly Horvath Oct 10 '16 at 23:15
  • what is the output of `if true; then echo yes; fi` ?? –  Oct 10 '16 at 23:16
  • Check with your system administrator. Your login shell may have changed. – alvits Oct 10 '16 at 23:19
  • and what is the output of `echo "$IFS" | od -An -vt 'x1c'` ? –  Oct 10 '16 at 23:23
  • @Robert, that code may "work", but it doesn't do what the OP wants it to. It's checking whether `1=1` is a non-empty string, not comparing the `1` on the left to the `1` on the right. Thus, it would also say that `0=1` was true as well. – Charles Duffy Oct 10 '16 at 23:28
  • @CamHashemi, run `set -x` as a command, which will make the shell log all subsequent commands that are run. – Charles Duffy Oct 10 '16 at 23:30
  • @CamHashemi, ...btw, are you entering content **exactly** as given here? If you were leaving off the final `;`, for instance, then hidden characters (such as CRs) could prevent your `fi` from being parsed as such. This is a common problem when copying scripts that were written on other platforms (ie. DOS systems) over to UNIX machines. – Charles Duffy Oct 10 '16 at 23:31
  • (Similarly: Typing by hand, or copying-and-pasting? If the latter, the clipboard can potentially contain nonprintable characters). – Charles Duffy Oct 10 '16 at 23:32
  • ...if this is strictly an interactive bug, rather than one that can be reproduced when running a script from a file, you might consider [Unix SE](https://unix.stackexchange.com/) or [SuperUser](https://superuser.com/) -- this is generally where the line between what's a programming question and what's an end-user question regarding the shell tends to be drawn. – Charles Duffy Oct 10 '16 at 23:34
  • ...btw, another thing you might look for is aliases. If you have one named `fi`, for instance, there's your problem. :) – Charles Duffy Oct 10 '16 at 23:35
  • @CharlesDuffy About aliases: That's why I asked for `type if` output. –  Oct 10 '16 at 23:44
  • @sorontar, it can't be `if` that's aliased -- we wouldn't get into the parser state in question, at least without it doing something else that starts a compound command; and `else` would just be a syntax error in that scenario. `fi`, though, could be our culprit. – Charles Duffy Oct 11 '16 at 00:28
  • @CharlesDuffy Try `alias if=echo` and then the line from the user. Indeed an alias of `if` (or `then` or `fi`) could well be the problem. –  Oct 11 '16 at 00:38
  • @CharlesDuffy: `alias if='{ if'` :-). Given that the question is not about the spacing error, why did you close it as duplicate? – rici Oct 11 '16 at 01:54
  • @rici, I had the same initial read that led to the existing answer. Frankly, on review, I agree that it's not a duplicate, but it's also not a good question without some editing: I can't see a way this won't fall under the rubric of "resolved in a way unlikely to help others", unless given a title and summary that'll filter for folks with the same actual problem. Right now, it *reads* very much as the "missing-spaces-around-the-operator" question that both sorontar and I took it for at first glance, and I don't feel so bad about leaving it that way until it's improved. – Charles Duffy Oct 11 '16 at 02:38
  • @rici, ...and you've motivated me to make that improvement myself. *Hopefully* the assumptions are accurate -- would have been better if the OP had done it. – Charles Duffy Oct 11 '16 at 02:43

1 Answers1

1

The most plausible situation here is that an element of your syntax is being overridden by an alias. Consider for instance:

alias fi=file
if true; then echo 1; fi

...will thus read to the shell as:

if true; then echo 1; file

...and it'll still be waiting for more input.

Consider using functions instead of aliases to avoid this kind of problem. For instance:

fi() { file "$@"; }

...will properly report a syntax error, rather than letting you define something with a dangerous name.

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • 2
    Another possibility is that the spaces following the semicolons are actually U+00A0 (non-breaking space). That will prevent the words `then`, `else` and `fi` from being recognized as such (since they are actually preceded by what bash considers a non-whitespace character) and so bash will still be looking for a real `then`, so it will prompt again. – rici Oct 11 '16 at 03:10
  • Charles Duffy was right. I had an alias named `fi` for "fix imports". Renaming the alias fixed it. – Cam Hashemi Oct 11 '16 at 17:50