The bugzilla server script is written in perl and I construct command 
strings of the form
   ssh $user@$host "cd $dir; $cmd $options > /dev/null 2>&1"
Then I use system($command);
Thanks for the -e -u; minor nitpicks to you are useful groomings for the 
rest of us.  It'll be my new prefix   :)

On Wednesday, December 5, 2012 10:13:44 AM UTC-5, Konstantin Khomoutov 
> On Wed, 5 Dec 2012 05:10:30 -0800 (PST) 
> Jeffrey Marans < <javascript:>> wrote: 
> > I thought the only possible solution was to have a complete set of 
> > repositories local to the bugzilla server, as per your first 
> > suggestion. Thanks for pointing out a far more practical method. 
> In fact, I suspect the first approach could be made less heavy-weight 
> using shallow cloning so that each local clone keeps only a minimum 
> amount of history since your requirements for branching seemingly do 
> not require forking new branches off anything other but extsting 
> branches, that is, "history tips".  But I have no experience with this 
> kind of setup so can't really say if it would work or not. 
> > I thought that sending ssh commands to the GIT server would not work 
> > because there's no .git sub-directory  and no working tree in each of 
> > the central repositories.  But commands like 'ssh git@git 
> > "cd /oacis/test; git branch -lf R73_23333_bug R73"' work just fine. 
> That is correct.  The SSH client has nothing to do with anything local. 
> Using Git's SSH transport actually just employs the fact SSH provides 
> both scripting *and* tunnelling, so, say, `git fetch` uses SSH 
> to connect to the server, authenticate, and spawn `git-upload-pack` 
> there; it then spawns `git-receive-pack` locally and then those two 
> processes are made communicate with each other through their standard 
> I/O streams which got connected via SSH.  So it's the local Git process 
> which actually accesses the Git repository data (under ".git"), not the 
> SSH client, which knows nothing about Git.  The same "trick" is 
> routinely exploited by tools like rdiff-backup, which connects via SSH 
> to the client, spawns `rsync` there and another `rsync` locally and 
> then makes them communicate. 
> One minor nitpick about your 
> 'cd /oacis/test; git branch -lf R73_23333_bug R73"' 
> script. 
> The Unix shell is notorious for its strange approach to error handling: 
> by default, if a command fails, nothing at all happens unless some 
> other command cares to inspect the return code and do something if 
> it's not zero or unless a compound command is created using '||' or 
> '&&'.  So, if, for instance, /oacis/test suddenly vanished for whatever 
> reason or became inaccessible (say, someone messed up its 
> permission/ownership data) your `cd` command will silently fail and the 
> shell will happily continue with running the next command.  So I would 
> advise to always start your scripts with the `set -e -u` command, which 
> switches the shell to the "fail on any error and on access to an unset 
> variable" mode.  This usually makes failures of shell scripts more 
> sensible to understand and debug. 


Reply via email to