Documentation for #! ?
Build Forge 7.1.2. I had vague memories of #! (sharp bang,
number sign exclamation point) working at the start of a step. It took me way way too long to figure out that a step beginning #! e:\cygwin\bin\bash.exe (produces "EXEC Unable to start system process - error 2" -- thanks a lot for the explanatory message, Build Forge) cannot have that space and must be #!e:\cygwin\bin\bash.exe I tried to look in the Build Forge help for #!, but I can't seem to find it. Where do I look? BTW, some experimetnal results: Starting with #!${CYGWIN_HOME}\bin\bash.exe doesn't work even when CYGWIN_HOME is set in an environment. The hack I use for such cases, when the default shell is CMD.exe, is .tset env "_NO_PREPARSE_COMMAND=1" goto SKIP_BASH 2>nul: set -o igncr # exit :SKIP_BASH %CYGWIN_HOME%\bin\bash.exe %0 exit /b %ERRORLEVEL% The "goto" is a command-not-found in bash. Seriously ugly and an abuse of bash, but it works if you don't need dot commands in the middle. In my case, the build agent is running on a Windows box and the shell I want to run is bash from Cygwin. The script as written to disk by Build Forge has lines ending in \r\n (carriage return newline). Default bash vomits on such lines. Cygwin (>= 2007, I think) added a Cygwin extension, a shell option called igncr. igncr strips carriage returns from all lines, including continuation lines like cmd arg1 arg2 \ arge3 arg4 arg5 and "here documents", like od -t x1 -a <<EOF a test line of input to od second line of input EOF The trailing comment character "#" on set -o igncr # makes the carriage return not hurt that one line. -- Tim McDaniel, tmcd@panix.com |
2 answers
|
In article <imitjk>,
rhaig <rhaig> wrote: #! is syntax of bourne shell, not buildforge. Thus we don't document #! is not Bourne shell. A UNIX-like _operating system kernel_ looks for "#!" as the first two bytes of a file, and if so, it interprets the rest of the line as the command interpreter to invoke. Bourne-like shells do not catch "#!"; they just treat it as a comment, because it starts with "#". Also, the text that follows "#!" does not have to be the Bourne shell or any command shell. For example, I've used "#! /bin/sed" and "#! /usr/bin/perl". Neither CMD.exe nor Microsoft Windows do anything with #!. Since #! works in Build Forge, Build Forge must be looking for #! and interpreting it. Also, I'm moderately sure that I saw "#!" in Build Forge documentation, back when it had built-in help. -- Tim McDaniel, tmcd@panix.com |
|
In article <imio2d>,
Tim McDaniel <tmcd> wrote: I tried to look in the Build Forge help for #!, but I can't seem to Finally found it. Searching in Rational's Information Center for "#!" gives no hits. "step" is of little use. "shell" turns out to be the magic word. <https> Developing > Working with steps > Controlling execution flow How steps run "You can use the #! directive to specify the shell to use to run the commands. This works on Windows(R) as well as Linux(R) and UNIX(R) systems (the Windows agent handles passing the commands to the specified interpreter)." If you want to use #!, do read the section for an important problem to avoid, about the current directory when the step starts. Note that its examples have "#!" followed immediately (no whitespace) by the command, and if you do insert whitespace you get "system error 2", but it does not say that that's required. It also has "How the system splits a step into parts", which would have saved me a day of experimentation last year. Every dot command runs as its own script and terminates the previous script. The reason I didn't see it is because you apparently can't search the help system for punctuation, and I had looked in Developing > Working with steps > About steps not expecting a topic like "How steps run" to be under another path like Developing > Working with steps > Controlling execution flow In passing, I should also note <https> Installing and upgrading > Installing agents > Configuring the agent bfagent.conf reference You can select a different default command interpreter for your entire system. -- Tim McDaniel, tmcd@panix.com |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.