obvious candidates would be environment variables or pwd. But to really know what’s happening we will (obviously) need the scripts and / or at least the error message + traceback.
[11:06:31]pankow@ldas-pcdev1:1014>./1014insp.sh 22
ROOT initialization starting.
Loading Wavelet Analysis Tool library.
Loading WAT macros.
Done. Starting.
Processing /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C...
Runnum/runID: 22 22
Processing /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C...
network of H1xH2 detectors
maximum time delay between detectors: 0
maximum time delay difference: 0
skymap angular resolution: 1
skymap size in polar angle: 46, 48
skymap size in azimuthal angle: 7.5, 9.5
constraint: 0.02 2
Tue Nov 13 11:06:39 PST 2007
ldas-pcdev1
job ID: 22
Input : /archive/home/pankow/m31event/inspiral/input/, label: CWB
Output: /archive/home/pankow/m31event/inspiral/output/background/1014/r22/, label: CWB
Reading injection log: /archive/home/pankow/m31event/inspiral/output/background/1014/r22//injectionList.txt
type 0 has been assined to waveform insp_1.400000-10.000000
GPS: 854378484.000000 saved, injections: 1
/usr1/igor/waveburst/data64/Meyer1024_L3.dat
*** Break *** segmentation violation
Generating stack trace...
0x00002ba8545fea56 in detector::readFilter(char const*) + 0x346 from /archive/home/pankow/wat/wat-4.7.0/lib/wavelet.so
0x00002ba85465dad5 in <unknown> from /archive/home/pankow/wat/wat-4.7.0/lib/wavelet.so
0x00002ba851b81c0b in G__call_cppfunc + 0x21b from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b6c06e in G__interpret_func + 0x143e from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b60428 in G__getfunction + 0x2288 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851bf933b in G__getstructmem + 0x5eb from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851bf1313 in G__getvariable + 0x953 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b33327 in G__getitem + 0x97 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b34e27 in G__getexpr + 0x737 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851ba0f12 in G__exec_statement + 0xda2 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851ba414a in G__exec_loop + 0x29a from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851ba4a6c in G__exec_for + 0x1dc from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851ba1e8b in G__exec_statement + 0x1d1b from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b20075 in G__exec_tempfile_core + 0x2c5 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851b20392 in G__exec_tempfile + 0x12 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba851bb08b7 in G__process_cmd + 0x6227 from /opt/lscsoft/root/lib64/libCint.so
0x00002ba8511eec9a in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) + 0x1da from /opt/lscsoft/root/lib64/libCore.so
0x00002ba851129935 in TApplication::ProcessFile(char const*, int*) + 0x425 from /opt/lscsoft/root/lib64/libCore.so
0x00002ba851126dcf in TApplication::ProcessLine(char const*, bool, int*) + 0x53f from /opt/lscsoft/root/lib64/libCore.so
0x00002ba8533dabc4 in TRint::Run(bool) + 0x164 from /opt/lscsoft/root/lib64/libRint.so
0x000000000040108d in main + 0x4d from /opt/lscsoft/root/bin/root.exe
0x00002ba853bd840f in __libc_start_main + 0xef from /lib64/libc.so.6
0x0000000000400fa9 in TApplicationImp::ShowMembers(TMemberInspector&, char*) + 0x41 from /opt/lscsoft/root/bin/root.exe
hmm, and echo 22| root -q -l -b /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C works? Really absolutely sure, also with the echo and -q -l -b and the exact same scripts? What about bash
echo 22| root -q -l -b /archive/home/pankow/m31event/inspiral/output/background/1014/parH1H2wa.C /archive/home/pankow/m31event/inspiral/output/background/1014/wanet2.C
Does that do it? Maybe you could compare env from the prompt and env from inside the script?
OK, very good Now compare the output of env on your prompt and in the sub-shell. When starting bash something must be changed by .bash_profile or /etc/profile or one of those.
Cheers, Axel.
So, it’s been fixed. (Sort of – it now breaks further down the line, with less explanation)
However, I’m more concerned with how it was fixed.
The reading of command line arguments was originally accomplished by an echo into the stdin of the root process. This was in a script wide scope. It was then changed to being passed as a parameter to a function inside the script.
it’s hard to tell without being able to reproduce it. I believe it might be due to a conflict in who redirects what; maybe bash and root get in each other’s way when accessing stdin. Passing it as a function parameter func.C(22) is portable and known to work. So your work-around is the proper one.