1

I have this problem that has been bugging me for quite some time now. It is perhaps best explained by referring to the following (well-known) script:

@rem= 'PERL for Windows NT -- ccperl must be in search path 
@echo off 
ccperl %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 
goto endofperl 
@rem '; 

########################################### 
# Begin of Perl section 


$start_dir = $ARGV[0]; 

# 
# Fixed variable 
# 
$S = "\\"; 
$list_file = "c:".$S."list_file"; 
$list_add = "c:".$S."list_add"; 
$choosed = "c:".$S."choosed"; 


sub clean_file 
{ 
$status = system("del $list_file > NUL 2> NUL"); 
$status = system("del $list_add > NUL 2> NUL"); 
$status = system("del $choosed > NUL 2> NUL"); 
} 

# 
# Start of the script... 
# 

printf("add-to-src-control $start_dir...\n"); 

clean_file(); 
$status = system("cleartool ls -view_only -r -s $start_dir > $list_file"); 
open(LIST_ELEMENT,$list_file); 
while ($element=<LIST_ELEMENT>) 
{ 
chop $element; 
# printf " Processing $element "; 
if ($element =~ /CHECKEDOUT/) 
{ 
# printf(" checkedout file \n"); 
} 
else 
{ 
# printf " view private \n"; 
printf " Processing $element ...\n"; 

# 
# For files with spaces... 
# 
if ($element =~ / /) 
{ 
$status = system("cmd /c echo \"$element\" >> $list_add"); 
} 
else 
{ 
$status = system("cmd /c echo $element >> $list_add"); 
} 
} 
} 
close(LIST_ELEMENT); 

if (-e $list_add) 
{ 
$listelement = `type $list_add`; 
$listelement =~ s/\n/,/g; 
$status = `echo $listelement > $list_add`; 

$status = system("clearprompt list -outfile $choosed -dfile $list_add -choices 
-prompt \"Choose element(s) to put over version control : \" -prefer_gui"); 

if ($status != 0) 
{ 
# printf("\n Aborting ...\n"); 
clean_file(); 
exit $status; 
} 

# 
$listtoadd = `type $choosed`; 
$listtoadd =~ s/\n//g; 
printf("\n cleardlg /addtosrc $listtoadd"); 
$status = system("cleardlg /addtosrc $listtoadd"); 

clean_file(); 
exit $status; 
} 
else 
{ 
# printf("\n No files founded...\n"); 
clean_file(); 
exit $status; 
} 

# End of Perl section 

__END__ 
:endofperl

which can be found on "ClearCase: The ten best scripts".
Now, to avoid any misunderstanding, the script works just fine; I followed the steps (outlined on the above website) to reproduce the recursive add-to-source control functionality.

The question (or questions rather) that I have is this:

How do we exclude here files with certain extensions (*.asv or *.dll, for example) from being added to source control (more precisely, from being added to the list of elements returned; see second question below)?
(And similarly with folders.)

Is the line:

$status = system("cleartool ls -view_only -r -s $start_dir > $list_file");

the one to focus on?

My second question is of a rather "cosmetic" nature.
The input box which is produced once you run the script is (in my case, at least) far too small to accommodate the whole paths of the elements to be added to source control.
Is there a way to make sure that the full paths are always visible?
Would that be a matter of amending

$status = system("clearprompt list -outfile $choosed -dfile $list_add -choices 
-prompt \"Choose element(s) to put over version control : \" -prefer_gui"); 

or am I completely mistaken? That is all for now. Any help will be greatly appreciated!

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Trevor3
  • 31
  • 2

1 Answers1

0

As this old thread illustrates, it is best to have files to ignored put outside the ClearCase view rather than inside ;)

That being said, you need to combine the ct lsview -r (or a more elaborate version of that command, as shown in "How do I determine what files in my ClearCase local view have not yet been added to source control?") with a grep.
That means you would read from the parameters the path of a file containing all the grep regexp of the files you want to ignore, and you would put the result of the ct lsview -r through each "grep -v xxx" (in order to exclude any file that matches that specific pattern)

For Windows, GoW (Gnu on Windows) will provide you with a fully functional grep (along with 130 other Unix commands compiled as native win32 binaries).

The op Mahyar reports:

Since some of the UNIX apps (within Gow) were causing conflicts with other local routines, I had to switch back to using findstr.
So, essentially what I have done is just use

cleartool ls -view_only -r -s | findstr /vi "\.asv" f > $list_file. 

In so doing $list_file is generated, just as it ought to be (that is, including all View Private elements apart from asv-files).
Further, when embedded in the Perl-Script, the script runs smoothly to the end, pointing out only those errors which already existed.


Regarding the second question, I don't know to change the size of clearprompt or cleardlg (and once created, they cannot even be re-sized).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @Mahyar unix or Windows: it will work. For Windows, install GoW (Gnu on Windows): https://github.com/bmatzelle/gow/wiki/, and you will have `grep`. – VonC Aug 10 '12 at 09:32
  • @Mahyar what is your error message? Try the command in a DOS windows first, before calling it from your perl script. – VonC Aug 10 '12 at 09:44
  • I do not work on UNIX; I should have perhaps mentioned this first. Let us just forget about my second question and focus on the first one. I have now made the change from `$status = system("cleartool ls -view_only -r -s $start_dir > $list_file");` to `$status = system("cleartool ls -view_only -r -s | findstr /vi \".asv$ ^cleartool$\" $start_dir > $list_file");`, yet it does not work. Have I entered the syntax correctly? – Trevor3 Aug 10 '12 at 09:56
  • If I simply execute the line `cleartool ls -view_only -r -s | findstr /vi ".asv$ ^cleartool$" $start_dir > $list_file` in the considered folder (in my snapshot-view), I will receive an error saying that `$start_dir` cannot be accessed ("No such file or directory"). – Trevor3 Aug 10 '12 at 10:00
  • @Mahyar sure, `$start_dir` is a Perl variable, which has a value only executed in the script. For testing in a DOS windows, replace `$start_dir` with the **full path** of the root directory (or any sub-directory) of a snapshot view. – VonC Aug 10 '12 at 10:21
  • I see. Doing this properly, the following seems to be happening: on executing `cleartool ls -view_only -r -s $start_dir > $list_file` (with `$start_dir` being the appropriate path defined) the file `$list_file` is produced which includes all the view-private elements in `$start_dir`; so far so good. Now, if I opt for `cleartool ls -view_only -r -s | findstr /vi \".asv$ ^cleartool$\" $start_dir > $list_file` instead, `$list_file` is still produced, but its content is empty. So I suppose there must be something wrong with the command line used. – Trevor3 Aug 10 '12 at 11:33
  • @Mahyar yes, mainly the regex doesn't match any line. Try rather a `| grep -v "\.asv"`, much simpler than tinkering with the [windows `findstr` command](http://technet.microsoft.com/en-us/library/bb490907.aspx). Of course, that means installing GoW and adding it to your PATH. – VonC Aug 10 '12 at 11:38
  • Now then, this is getting interesting. I managed to install 'Gow', and upon executing `cleartool ls -view_only -r -s | grep -v ".asv$ ^cleartool$" c:\TestView\fldr01 > $list_file`, `$list_file` is generated, empty again, and the DOS-message returned is "grep: c:\TestView\fldr01: Is a directory" (which however does not show up explicitly as an error message). Note that here I am trying to compute `$list_file` such that it lists all the contents of `fldr01` for source control, including subfolders, but excluding asv-files. – Trevor3 Aug 10 '12 at 13:50
  • @Mahyar I didn't say to grep on such a complicated expression than `".asv$ ^cleartool$"`: try simpler: `| grep -v "\.asv"`, as I mentioned in my previous comment. Baby steps ;) – VonC Aug 10 '12 at 14:04
  • ;) I took your suggestion to heart, and that is what I have tried: `cleartool ls -view_only -r -s | grep -v "\.asv" c:\TestView\fldr01 > $list_file`; but I still get an empty file `$list_file` and a warning message which reads "grep: c:\TestView\fldr01: Is a directory". (I also tried a file extension different to `*.asv`, hoping that things would change, but that has not helped.) – Trevor3 Aug 10 '12 at 14:21
  • @Mahyar try even simpler: `cleartool ls -view_only -r -s > f ; grep -v "\.asv" f > $list_file`. If that still doesn't work, decompose each part to be sure of what they do. Then bring them back together. – VonC Aug 10 '12 at 14:41
  • VonC, you are a lifesaver! First things first; since some of the UNIX apps (within Gow) were causing conflicts with other local routines, I had to switch back to using `findstr`. So, essentially what l have done is just use `cleartool ls -view_only -r -s | findstr /vi "\.asv" f > $list_file`. In so doing `$list_file` is generated, just as it ought to be (that is, including all ViewPrivate elements apart from asv-files). Further, when embedded in the Perl-Script, the script runs smoothly to the end, pointing out only those errors which already existed. – Trevor3 Aug 13 '12 at 11:13
  • @Mahyar Excellent. I have included your conclusion to the answer for more visibility. – VonC Aug 13 '12 at 12:23
  • We are still not quite there yet. I have just realised that in the Perl-Script we need to execute `cleartool ls -view_only -r -s > f` before executing the command line `cleartool ls -view_only -r -s | findstr /vi "\.asv" f > $list_file`. The reason seems to be that, if done otherwise (that is, if `cleartool ls -view_only -r -s > f` is not executed first), `f` will not be generated. Even though it works, this is a rather ad hoc way to go. – Trevor3 Aug 13 '12 at 12:52