What is the best way to debug git-hooks?
The way I prefer is adding statements to add output to a log file. For example, the following.
echo 'post-receive executed' >> hooks.log
Is there a better approach or way to do logging?
This is an old question, but for future readers, one recommendation would be :
Debugging the hook as a shell script
I doubt that it is the script itself which needs to be looked at, however if that turns out to be the case, then the next step is to do what you normally would to debug shell scripts (since that is what the default commit-msg hook is).
I would start by changing the she-bang line from #!/bin/sh to #!/bin/sh -xv and then revel in the uber-verbose output as the script is executed when you do a git commit --amend
Related
i came across a problem with subversion at my work. I want to create a post-commit-hook (post-commit.bat file) command that creates information about the last transaction.
The code looks like this:
#echo off
set file="D:\mypath\logfile%2.txt"
svn log D:\'my path to repro'\ -r %2 -v > %file%
The %2 corresponds to the last revision number. It creates the file with the correct number and tries to write in it. But then the commit hangs and the file remains open. The curious thing is, if I manually trigger the command with a valid revision number, then the whole thing works. Only with the hook it hangs and it also does not commit the files.
Can anyone help me or have any ideas for my problem?
I found a solution, maybe this might be helpful for some person.
I used the wrong command "log". Instead you have to use "svnlook changed..." on the server to get the latest information about the last commit.
I have experienced (random) weird corruption of environment variables from consecutive calls of multiple (3d party) batch scripts. These individual scripts call #echo off.
Is it possible to force echo on by environment variable/other means or I need to go to the every script and comment/remove the line to see what has been actually executed?
I'm quite sure that this is not possible. You can't force your system to simply ignore a command like ECHO OFF. The only way to I can think of as a workaround is to write a script which replaces all ECHO OFF commands in you bat files before execution and restoring them afterwards.
Take a look at this: https://superuser.com/questions/351661/how-do-i-force-echo-on-for-a-batch-file-without-editing-the-file
I have to maintain a batch script of about 3500 lines littered with GOTO. Seems that the original "developer" hasn't heard of this famous paper and modular programming.
What the script does?
The script deals with the (silent) installation/uninstallation/reinstallation of several programs using different options. It could be split in several files that deal with each program in part. The problem is that if you're trying to take a part in another file that part will still GOTO another section that needs to be in the original script.
Refactoring?
Normally you wouldn't do a refactoring without having automated tests (so you can be sure you didn't break anything), but I don't know how to do it. There's no testing framework for that.
Partial Solution
I have come up with a partial "solution" that is some kind of adaptation of characterization tests (from Working Effectively with Legacy Code by Michael Feathers) and approval tests:
- create another script: test.py that replaces all commands (like copy or msiexec) with echo,
- redirect the output to a text file (good.txt),
- change the original batch script,
- run the test.py script again and save the output to another text file (current.txt),
- diff good.txt and current.txt -> if there are no differences then I didn't break anything, but if they are different I need to check if I broke something.
Problem with partial solution
How can I capture and replace all the commands? I could make a list of commands to replace, but there are also a lot of string concatenations to get the name and path of the program to be installed.
CMD level capture/hook?
Is there any way I can hook into the command line interpreter (CMD.exe) so I can replace on the fly all the calls to installers with echo?
Other suggestions?
Do I approach the problem in the wrong way? Can I do it better somehow? Do you have some advice I could use?
You could replace all COPY, DEL or CALL with %COPY%, %DEL% ,...
So you can use the same file for production and also for the tests.
#echo off
if not defined UNITTEST (
set "COPY=COPY"
set "DEL=DEL"
set "CALL=CALL"
)
%COPY% src dest
%DEL% somefile.txt
%CALL% installer.exe
And from your unittest.bat, you could start it via
#echo off
set "COPY=>>trace.log ECHO COPY"
set "DEL=>>trace.log ECHO DEL"
set "CALL=>>trace.log CALL ECHO "
del trace.log
set "unittest=Active"
call production.bat
fc good.txt trace.log
I'm not an expert in Batch, but I have done my fair share of it. With that said, I can offer a few tips.
Forget trying to do it all at once. Batch is very hard to debug. Echoing out to a log file helps a lot, but it will not capture everything you need if something goes wrong.
Work on breaking out the exe and msiexec calls into self-contained scripts. It is much easier to test the small script for the functionality you desire. Once you have that working, it is simple to call that script from the "Master" script.
Establish a good protocol for passing args to, and return codes from the smaller scripts. If there are common settings needed to be used for all the scripts consider using a central settings file.
GOTOs are not the devil, unless they pass control all over the place. Normally there are two good reasons that I know of to use GOTO’s.
Skip past a block of code that does not need to run.
To SET values into variables. Note there is a bug that can prevent variables from having their value set from within an 'IF' statement block. That little bug caused a big headache for me at one time.
Calls to a label might be better option at times.
Depending on how far back the legacy support is required, consider using Powershell when possible. The power and debugging capabilities of Powershell far out way the benefits of simple scripting of Batch. Which at 3500 lines simplicity has already been lost. You are already looking at Python, so maybe that could be used instead.
If you need a break point, use Pause. ECHO all the settings you need to examine right before the pause. This is as close to a break point I have found for batch.
Echo the command you intend to run to a log file and actually run it.
Write small verification scripts to be used independently or with the “Master” script to confirm you are getting the results you are expecting.
Use the right tool for the job. I like to use EditPadPro, RegexBuddy, and BeyondCompare for batch editing and comparing differences. There free tools that can be used too NotePad++ and Windiff. Making many edits in a file of that size is best handled by a good editor. IE inserting an echo at the beginning of a line that calls a cmd.exe.
Remember it is scripting not programming. While there is a lot of overlap of the two, the same exact approach to a problem may not be viable between the two.
Always make a backup copy of the scripts as a whole before mucking around. A fallback position is greatly appreciated when there is one small bug that you can’t find.
If it ain't broke... well you wouldn't be working on it if everything was working just fine.
Always test changes. And when you are done test it again. After that have someone else test it.
Just my .02. I’m sure someone else can chime in with more advanced advice. My knowledge on Batch has been acquired from the school of hard knocks, supplemented by ss64.com
I need to check in a script if a file was modified since I read it (another application can modify it in between). According to bash manual there is a "-N" test which should report if a file was modified since last read. I tried it in a small script but it seems like it doesn't work.
#!/bin/bash
file="test.txt"
echo "test" > $file
cat $file;
if [ -N $file ];
then echo "modified since read";
else
echo "not modified since read";
fi
I also tried an alternative way by touching another file and using
if [ "file1" -nt "file2 ];
but this works only on a seconds accuracy which may under rare conditions not be sufficient. Is there any other bash-inbuilt solution for this problem or I do really need to use diff or md5sum?
Comparing file hashes (md5/sha1) is probably the only robust way to know (and audit) file changes, lest someone attempt to circumvent your attempts to detect file modifications. Also, rather than (or in addition to) periodically polling, you could implement some kind of file change notification: see this s.u. question for suggestions (e.g., using inotifywait).
But if it seems your scripts are gradually converging on a revision control system, just put these files in a git repo and let git detect and manage the changes for you.
(Edit: I just noticed that these are scripts monitoring log files (I was thinking you were monitoring actual scripts for file changes), in which case putting them under version control really wouldn't be appropriate.)
I need a shell script which will allow me to typeset Lilypond files from TextWrangler (A Mac App).
So far I have come up with this:
#!/bin/sh
/Applications/LilyPond.app/Contents/Resources/bin/lilypond -o $1
which, of course, doesn't work. (That's why I'm at Stack Overflow.)
When I run that script from the shebang menu in TextWrangler, I get this output:
/Applications/LilyPond.app/Contents/Resources/bin/lilypond: option faultpaper,
--output'' requires an argument
What gives?
I'm running Snow Leopard, TextWrangler, and Lilypond.
Help appreciated.
EDIT: Found a way to get the document path in a Unix Script launched by TextWrangler, so I've rewritten this.
There are multiple ways to work with scripts in TextWrangler through the #! menu, and I'm not sure which one you're trying to use. It looks, though, like you're trying to create a Unix Script to convert your LilyPond document.
As your error hints, Unix Scripts unfortunately aren't given any arguments at all, so $1 will be empty. However, it turns out that recent versions of BBEdit/TextWrangler do set some environment variables before running your script (see BBEdit 9.3 Release Notes and scroll down to Changes). In particular, you can use the following environment variable:
BB_DOC_PATH path of the document (not set if doc is unsaved)
So, save this script to ~/Library/Application Support/TextWrangler/Unix Support/Unix Scripts and you should be good to go.
Other ways you might be trying to do this that don't work well:
Using a Unix Filter: to do this you would have to select all of your LilyPond code in the document, and it would be saved into a temporary file, which is passed as an argument to your script. OK, so that gets you an input filename, at the cost of some hassle. But then the output of that script (i.e. the LiiyPond compiler output) by default replaces whatever you just selected, which is probably not what you want. Wrong tool for the job.
Using #! → Run on a LilyPond file: This involves putting a #! line at the top of your file and having TextWrangler attempt to execute your file as a script, using the #! as a guide to selecting the script interpreter. Unfortunately, the #! line only works with certain scripting languages, and LilyPond (not quite a scripting language) isn't one of them. This is what Peter Hilton is trying to do, and as he notes, you will get LilyPond syntax errors if you try to add a #! line to the top of a LilyPond file. (If you're curious, there is technically a way to get #! → Run to work, which is to embed your LilyPond code inside an executable shell or perl script, using here-document syntax. But this is a gross hack that will quickly become unwieldly.)
There are a few limitations to the script linked above:
It doesn't check to see whether you saved your document before running LilyPond. It would be nice to have TextWrangler automatically save before running LilyPond.
It can't take snippets of text or unsaved documents as input, only saved documents.
You can make more sophisticated solutions that would address these by turning to AppleScript. Two ways of doing this:
Create a script that's specific to TextWrangler and drop it in ~/Library/Application Support/TextWrangler/Scripts. It then shows up in the AppleScript menu (the weird scrolly S), or you can get at it by bringing up Window → Palettes → Scripts. I believe two folks out there have gone down this path and shared their results:
Henk van Voorthuijsen (Lilypond.applescript extracted from MacOS 10.5 Applescript for TextWrangler thread on lilypond-devel, 21-Jul-2008)
Dr Nicola Vitacolonna (LilyPond in TextWrangler – uses TeXShop).
Create a Mac OS Service, which would potentially be a method that would be reusable across just about any text editor. This was how we used to compile Common Music files way back in the NeXT days, so I can testify to its elegance. I don't have a good up-to-date example of this, unfortunately.
Good question. It actually runs Lilypond on my system if you do this:
#!/Applications/LilyPond.app/Contents/Resources/bin/lilypond -o $1
… but fails because # is not a line-comment character so Lilypond tries to parse the line.
Surrounding it with a block comment fails because TextWrangler cannot find the ‘shebang’ line.
%{
#!/Applications/LilyPond.app/Contents/Resources/bin/lilypond -o $1
%}
An alternative is to use Smultron 3, which lets you define commands that you can run with a keyboard shortcut.