Invoking external commands with options from a makefile - command-line

I have a makefile for compiling Arduino programs.
I need to add some text at the beginning of some files based on some logic. I am using echo command for that.
ECHO = echo
and later in the file, I have lot of places like
$(OBJDIR)/%.cpp: %.pde
$(ECHO) '#if ARDUINO >= 100\n #include "Arduino.h"\n#else\n #include "WProgram.h"\n#endif' > $#
which works fine.
Recently, some users complained that echo command doesn't work properly in some linux distros and I had to add the '-e' option to the echo command.
So I changed the first line where I declare the command to
ECHO = echo -e
This is not working, because makefile considers -e as part of the text and not as part of the option.
Edit:
I am not getting any error, but the text -e is also appended to the file that I am creating.
Is there a way to declare the -e as an option and not as part of the text?

Most likely you're seeing behavior differences because echo is a shell built-in command in some versions of some shells. Then that's being compounded because make only sometimes uses the shell to invoke commands -- it will prefer to invoke commands directly if possible. So, sometimes, on some systems, you are not invoking the echo command that you think you are.
You would probably have better luck by setting
ECHO = /bin/echo -e
which will explicitly invoke the external echo command, even if the shell has a built-in version. That way you should get consistent results.

if get /bin/sh: 1: -e: not found error it's related to your shell, not makefile.else, please put your error. of course if you get error.

Related

redirecting echo with undefined variable

I'm running a script in solaris 11 with different results depending of the shell used.
The script has an echo redirecting to a file given by an environment value:
echo "STARTING EXEC" >> $FILE
ps. EXEC is just the message the script show, it's not using exec command.
If I execute the script without the variable FILE defined (using /usr/bin/ksh):
./start.sh[10]: : cannot open
and the script continue the execution.
The flags for ksh are:
echo $-
imsuBGEl
But if I change to /usr/xpg4/bin/sh, the script show me the echo in stdout and there is no error shown.
The flags for xpg4 sh are:
echo $-
imsu
I tried to change the flags with set +- (I can't remove El flags, but BG are removed ok), but can't get the same behavior.
Is there anything I can do to get the same result using ksh without cannot open error?
/usr/bin/ksh --version
version sh (AT&T Research) 93u 2011-02-08
I'll want the script keep going, showing the message in stdout, instead of showing the error just like it does now.
Like shellter said in the comments, the good thing to do is to check if the FILE variable is defined before doing anything. This is a script migration from an HPUX to a SOLARIS environment, and client think they must have the same result as before (we unset FILE variable before execution to test it).
You are likely running Solaris 11, not Solaris 64.
Should you want to have your scripts to work under Solaris 11 without having to search everywhere the bogus redirections, you can simply replace all shebangs (first line) by #!/usr/xpg4/bin/sh.
The final solution we are going to take is to install the ksh88 package and use it like default shell (/usr/sunos/bin/ksh). This shell have the same behavior the client had before, and we can let the scripts with no modifications.
The ksh used in solaris 11 is the 93 (http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html#shell-1)
Thanks #jlliagre and #shellter for your help.

Perl running a batch file #echo command not found

I am using mr on Windows and it allows running arbitrary commands before/after any repository action. As far as I can see this is done simply by invoking perl's system function. However something seems very wrong with my setup: when making mr run the following batch file, located in d:
#echo off
copy /Y foo.bat bar.bat
I get errors on the most basic windows commands:
d:/foo.bat: line 1: #echo: command not found
d:/foo.bat: line 2: copy: command not found
To make sure mr isn't the problem, I ran perl -e 'system( "d:/foo.bat" )' but the output is the same.
Using xcopy instead of copy, it seems the xcopy command is found since the output is now
d:/foo.bat: line 1: #echo: command not found
Invalid number of parameters
However I have no idea what could be wrong with the parameters. I figured maybe the problem is the batch file hasn't full access to the standard command environment so I tried running it explicitly via perl -e 'system( "cmd /c d:\foo.bat" )' but that just starts cmd and does not run the command (I have to exit the command line to get back to the one where I was).
What is wrong here? A detailed explanation would be great. Also, how do I solve this? I prefer a solution that leaves the batch file as is.
The echo directive is executed directly by the running command-prompt instance.
But perl is launching a new process with your command. You need to run your script within a cmd instance, for those commands to work.
Your cmd /c must work. Check if you have spaces in the path you are supplying to it.
You can use a parametrized way of passing arguments,
#array = qw("/c", "path/to/xyz.bat");
system("cmd.exe", #array);
The echo directive is not an executable and hence, it errors out.
The same is true of the copy command also. It is not an executable, while xcopy.exe is.

Run Coffeescript Interactive (REPL) with a script

In python, I can run a script and enter interactive mode in the context of that script. This lets me mess with global variables and what not to examine program state.
$ python -i hello.py
Can I do this with Coffeescript? I've tried the following:
$ coffee -i hello.coffee
doesn't load hello.coffee. It's equivalent to coffee -i
$ cat hello.coffee | coffee -i
runs the script line by line in REPL but ends REPL after the EOF.
I've recently started a project to create an advanced interactive shell for Node and associated languages like CoffeeScript. One of the features is loading a file or string in the context of the interpreter at startup which takes into account the loaded language.
http://danielgtaylor.github.com/nesh/
Example:
# Load a string
nesh -c -e 'hello = (name) -> "Hello, #{name}"'
# Load a file
nesh -c -e hello.coffee
Then in the interpreter you can access the hello function. Also a good idea to create an alias in bash:
alias cs='nesh -c'
cat foo.coffee - | coffee -i
tells cat to first output your code and then output stdin, which gives you what you're looking for I think.
I am confronted with this problem as well. The one provide by #int3 doesn't solve this problem, for CoffeeScript is one indentation based language. stdin will pass the code line by line, but the repl is not smart enough to realize this. Since you post this question, I suggest you create one issue (feature request) on CoffeeScript

ant: command not found

I am having some trouble running ant. Here is a simplified verison of my problem. I have a shell script script1.sh:
export ANT_HOME=/opt/Ant
ant -version
This works. but when I try create another script script2:
cd /location/of/script1
sudo -E ./script1.sh | tee log.txt
I get the error ant: command not found. Does anyone know why this is happening.
Sounds like you're losing your PATH setting after sudo. Try adding echo $PATH in script1.sh to see the before and after values. Or just define script1.sh as
export ANT_HOME=/opt/Ant
${ANT_HOME}/ant -version
Without knowing what shell, or seeing more of the scripts it's hard to tell exactly what is happening. But if you want script2 to know about ANT_HOME you're probably going to need to source or eval script1. See here. Also I know pipes '|' cause Bash to perform operations within sub-shells which can be problematic under certain circumstances (if you're using Bash).
EDIT:
Double check that you are using the version of ant that you think you are:
#!/bin/bash
# Capital A here seems suspicious to me...
export ANT_HOME=/opt/Ant
echo "`${ANT_HOME}/ant -version`"

Run a command as cron would but from the command line

I have a script that I'm trying to run from cron. When I run it from bash, it work just fine. However when I let cron do it's thing, I get a:
myscript.sh: line 122: syntax error: unexpected end of file
What I want is a way to run a command as if it was a cron job, but do it in my shell.
As a side note: does anyone know what would be differnt under cron? (the script already has a #!/bin/sh line)
To answer my own question: I added this to my crontab:
* * * * * bcs for ((i=$(date +\%M); i==$(date +\%M) ;)) ; do find ~/.crontemp/ -name '*.run' -exec "{}" ";" ; sleep 1; done`
and created this script:
#!/bin/sh
tmp=$(mktemp ~/.crontemp/cron.XXXXX)
mknod $tmp.pipe p
mv $tmp $tmp.pre
echo $* '>' $tmp.pipe '1>&2' >> $tmp.pre
echo rm $tmp.run >> $tmp.pre
chmod 700 $tmp.pre
mv $tmp.pre $tmp.run
cat $tmp.pipe
rm $tmp.pipe
With that, I can run an arbitrary command with a delay of not more than one second.
(And yes, I know there are all kinds of security issue involved in that)
the problem was a fi vs. if problem. Doh!
When a script works interactively and fails in cron it's almost always a PATH problem. The default PATH in a cron job process is much much shorter than in an interactive session. The typical result is a "not found" error for some system utility you're trying to run that is not on the PATH in cron.
I would guess that some command you're trying to run is not on the path, therefore the file it was supposed to create is empty and the command that's trying to read that file is giving you this error message.
You may have a "%" in your crontab.
You must escape it (with "\") or it is changed in a newline character.
There are a number of things it could be - output will be redirected elsewhere; environment variables will almost certainly be different, etc. On the information you've given, it could be related to a difference between bash and /bin/sh (which on some systems - including Debian/Ubuntu flavors of Linux - are different, and support slightly different syntax). Cron will usually run the command you give to it using /bin/sh.
Try running:
/bin/sh -c '<command>'
where <command> comes from your crontab. (Of course, if that command uses '' quotes you will need to modify it accordingly...)