-4

I'm having an issue with a bash script that produces out of order output.
This script is used in multiple places and usually works fine.

In one specific directory however, it goes all out of sync and makes its output file useless.
The directory structures are identical and the input data it takes are very similar. (Working in ClearCase if that makes a difference.)

When the bash is functional its output looks like this:

Techpack Meta Version is currently 3, has this changed? y/n n
Have Techpack Version Dependencies changed? y/n n
Updating Version Properties

Building TPI File
Inside make_tpi_file
Created ../package/12.0/M_E_LCHS_DATAGEN_R0E_b1.tpi
Checked out "package/12.0/" from version "/main/at_job/1".
Created element "package/12.0/M_E_LCHS_DATAGEN_R0E_b1.tpi" (type "compressed_file").
Created branch "at_job" from "package/12.0/M_E_LCHS_DATAGEN_R0E_b1.tpi" version "/main/0".
Checked out "package/12.0/M_E_LCHS_DATAGEN_R0E_b1.tpi" from version "/main/at_job/0".
Checked in "package/12.0/M_E_LCHS_DATAGEN_R0E_b1.tpi" version "/main/at_job/1".
Checked in "package/12.0/" version "/main/at_job/2".

When the bash is not functional its output looks like this:

Techpack Meta Version is currently 3, has this changed? y/n n
Have Techpack Version Dependencies changed? y/n n
Updating Version Properties

Building TPI File
Inside make_tpi_file
_R0E_b1.tpipackage/12.0/M_E_HANF_DATAGEN
Checked out "package/12.0/" from version "/main/at_job/4".
_R0E_b1.tpi" (type "compressed_file").A_DATAGEN
_R0E_b1.tpi" version "/main/0".package/12.0/M_E_HANF_DATAGEN
_R0E_b1.tpi" from version "/main/at_job/0".
_R0E_b1.tpi" version "/main/at_job/1".GEN
Checked in "package/12.0/" version "/main/at_job/5".

/vobs/job/job_mg/test_tools/Data_Generator/HANF/FeatureTest/build
Checked in "install/version.properties" version "/main/at_job/14".
Checked in "../package/12.2/build.number" version "/main/at_job/4".

What could cause a bash script, in general, to produce such a mangled output?
Considering it works fine for many directories, I don't think the issue is in the code itself, rather in the data read by the script.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
patrick
  • 7
  • 1
  • 3

2 Answers2

6

Seriously, do you expect us to debug a script while only seeing its output?

That's quite a tall order.

Still, my guess would be (and note that it can't be more than a guess, since I don't know what the script is doing) some kind of race condition, where steps of the script depend on each other but are not forcibly synchronized, causing failure when they complete in an unexpected order.

Citing "the code was copied from somewhere" as a reason it should be free of errors is also quite outrageous, really.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • Hey Sorry for the rough question guys. My apologies. Thanks for reading and giving a suggestion unwind. Turns out my issue was the script mentioned above reads variables from another file. Some of said variables had trailing white space characters which was the cause. Just thought I'd though in what the solution was. Sorry again for a poor question. – patrick Jun 21 '12 at 16:02
0

Note: what you script is supposed to do is:

  • checkout the parent directory of the tpi file
  • create the element (file) tpi (cleartool mkelem)
  • checkout that (new and empty) element
  • (its content gets overwritten by the actual tpi file being build)
  • checkin that file
  • checking the parent directory.

You need to check how your bash script is calling the clearcase commands, because it seems there is a flushing issue (similar to " Getting another program's output as input on the fly ")

This can happen if you script is setting a dynamic view: see "Python and ClearCase setview": the cleartool setview creates a sub-shell, which can make the output a bit random.

In the OP's case, patrick reports:

My issue was caused by hidden white space characters in the read variables:
my issue was the script mentioned above reads variables from another file.
Some of said variables had trailing white space characters which was the cause.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250