Is there a way to mute or remove error messages from a Clearcase command such as mklabel? I'd like to suppress error messages from the mklabel command if possible.
The scripts you see in this thread (or this one, or in one of the ten best scripts) usually employ the same technique:
cleartool mklabel ... 2> /dev/null
In a perl script for instance:
my $cout = `cleartool desc $pn##\/$lbtype 2>/dev/null` ;
This is part of cleartool output redirection techniques.
I prefer redirecting stderr in a file, that I can parse (after executing the command) to detect rare errors, while ignoring all the warning (like label already existing and moved).
But the main idea remains: for a cleartool mklabel, there is no -silent or -quiet option.
Related
I checkout a powershell file and signing it if it is not signed already then check-in back.
But my check-in fails as saying identical to predecessor. What is the cleartool command to undo checkout if it is identical to previous version?
You can simply try:
cleartool unco
That is "undo checkout"
Now you cannot do that in the checkin command itself.
What you can do is a cleartool diff: if there is no difference detected, then you unco, if there are, you check in.
You have that approach detailed in this thread:
You may need to diff against the previous version, but you can use something like diff <file> <file>##/main/branch/version, and if different (or whatever that diff returns if they are different), then allow the checkin to succeed). Otherwise maybe unco -rm the file.
Or:
In our makefile we have a section that basically follows the following format for each file:
call checkin_if_changed.bat "dir1\sub\file.h"
The contents of the file "checkin_if_changed.bat" are as follows:
cleartool diff -pre -dif %1
echo File: %1 diff result: %ERRORLEVEL%
goto diff%ERRORLEVEL%
:diff1
cleartool ci -c "Build box build." %1
goto end
:diff0
cleartool unco -rm %1
:end
Basically we do a cleartool diff against the prev version of the file.
If the cleartool diff returns a 0 it means the files are identical, so we do an unco -rm.
If cleartool diff finds a difference it returns a 1, meaning the files are different, and we check it in.
Or:
I've used the somewhat messy:
cleartool lsco -cvi -avo -fmt "ci -nc '%n'\nunco -rm '%n'" | cleartool
If the file is identical (and fails the checkin), then it unchecks it
out.
If it isn't identical, it checks it in, then the unco command
fails (since it's not checked out) with an error (but continues).
You can dump all of the output to a log file if you don't want to see it on
the command line. You can probably refine that if you need to.
If you have a post checkin trigger that forces you to enter a comment, then
change the -nc to -c 'some comment' instead.
I am trying to label all the elements within a branch of a view, but some of the elements do not get labeled and instead give me a "No such file or Directory" error. I can see the files that generated the error in my command window, but they are highlighted in red. It seems like these files are not there and are thus generating the error. How can I remove these "files" from the view so that the labeling can continue and not generate errors?
Say that bolded words represent red highlighting. This is what I see:
file1 file2 directory1 directory2
Here is how my code is structured in my shell script:
cleartool mkview -tag $VIEWNAME ... (etc.)
cleartool setcs -tag $VIEWNAME configSpec.txt
cd /projectDirectory
labelname=`date "+%b-%d-%y"`
cleartool mklbtype -nc $labelname
cleartool mklabel -recurse $labelname /projectDirectory
The script starts recursing through the file tree from the projectDirectory. When it encounters file1 or directory1, I get the "No such file or directory" error. Otherwise, for file2 and directory2, the labeling occurs properly.
So, my question is this: How can I use the mklabel command or some other method to label all the files that are not highlighted in red?
You must first know the exact status of the "files in red"
For that, go in a shell to their parent folder, and type:
cleartool ls
That will give you their status (eclipsed?, private? other?), which will explain why the label cannot proceed.
Possible causes:
the files are symlinks
the files have spaces in their names (that shouldn't be the case here: cleartool mklabel should support that case)
the files are in the lost+found folder (solution: exclude that folder from your view with a -none selection rule)
Note: if an element isn't selected (no version selected and Rule: -none), then a recurse mklabel is supposed to generate that error message, but that won't prevent the label to be set on the other elements version.
So that error message should be safely ignored.
When starting Catalina run, I get the following warning:
WARNING: ClearCaseRepository not working (missing binaries?):
Any idea, anyone?
Thanks, Avi
This is similar to this thread (I will adapt the following extract to your case):
As far as I can see from the code, this warning can only happen if the command "git --help" [in your case cleartool -version] exits with a non-zero exit code.
What do you see if you log in as the tomcat user, set the PATH like you do in startup.sh, and then execute following commands
cleartool -version
echo $?
Check the logs (catalina.out) after adding the following line to your Tomcat's conf/logging.properties:
org.opensolaris.opengrok.level=ALL
I would like to list the available labels matching a particular string applied in the view.
I confirm a filter in cleartool find is not possible:
ct find . -ele "lbtype_sub(My_LAB*)" -print
would not work (no wildcard in query argument.
If you cannot use a grep in a shell pipe, can you consider using grep in an exec part of a find, like in this example?
ct find . -kind lbtype -exec "echo %CLEARCASE_PN%|grep MY_LAB"
If this is not acceptable, you need to write the result in a file and process it with another tool (sed?)
You have packages for Windows including Unix commands: see this SO question.
Of you have freeware emulating the grep command.
If you must stay with native Windows commands, you must redirect the result in a file, and use FIND (English translation).
Hmm. I'm not entirely sure about this although the following will list all labels used for a given VOB (entered using ClearTool command line application).
lstype -kind lbtype -invob vob_path_and_name -short
for example with a View mapped to drive U: VOB "Some_VOB" would be:
lstype -kind lbtype -invob U:\Some_VOB -short
In a static view, how can I view an old version of a file?
Given an empty file (called empty in this example) I can subvert diff to show me the old version:
% cleartool diff -ser empty File##/main/28
This feels like a pretty ugly hack. Have I missed a more basic command? Is there a neater way to do this?
(I don't want to edit the config spec - that's pretty tedious, and I'm trying to look at a bunch of old versions.)
Clarification: I want to send the version of the file to stdout, so I can use it with the rest of Unix (grep, sed, and so on.) If you found this question because you're looking for a way to save a version of an element to a file, see Brian's answer.
I'm trying to look at a bunch of old versions
I am not sure if you are speaking about "a bunch of old versions" of one file, "a bunch of old versions" from several files.
To visualize several old versions of one file, the simplest mean is to display its version tree (ct lsvtree -graph File), and then select a version, right-click on it and 'Send To' an editor which accepts multiple files (like Notepad++). In a few click you will have a view of those old versions.
Note: you must have CC6.0 or 7.0.1 IFix01 (7.0.0 and 7.0.1 fail to 'sent to' a file with the following error message "Access to unnamed file was denied")
But to visualize several old versions of different files, I would recommend a dynamic view and editing the config spec of that view (and not the snapshot view you are currently working with), in order to quickly select all those old files (hopefully through a simple select rule like 'element * aLabel')
[From the comments:]
what's the idiomatic way to "cat" an earlier revision of a file?
The idiomatic way is through a dynamic view (that you configure with the exact same config spec than your existing snapshot view).
You can then browse (as in 'change directory to') the various extended paths of a file.
If you want to cat all versions of a branch of a file, you go in:
cd /view/MyView/vobs/myVobs/myPath/myFile##/main/[...]/maBranch
cat 1
cat 2
...
cat x
'1', '2', ... 'x' being the version 1, 2, ... x of your file within that branch.
For a snapshot view, the extended path is not accessible, so your "hack" is the way to go.
However, 2 remarks here:
to quickly display all previous revisions of a snapshot file in a given branch, you can type:
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
you can quickly have an output a little nicer with
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"' | ccperl -nle '$a=$_; $b = $a; $b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;print $b if $a =~/^>/'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
| ccperl -nle '$a=$_; $b = $a;
$b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;
print $b if $a =~/^>/'
That way, the output is nicer.
The "cleartool get" command (man page) mentioned below by Brian don't do stdout:
The get command copies only file elements into a view.
On a UNIX or Linux system, copy /dev/hello_world/foo.c##/main/2 into the current directory.
cmd-context get –to foo.c.temp /dev/hello_world/foo.c##/main/2
On a Windows system, copy \dev\hello_world\foo.c##\main\2 into the C:\build directory.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2
So maybe than, by piping the result to a cat (or type in windows), you can then do something with the output of said cat (type) command.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2 | type C:\build\foo.c.temp
I know this is an old thread...but I couldn't let this thrashing go by unresolved....
Static views have a "ct get" command that does exactly what you are looking for.
cleartool get -to ~/foo File##/main/28
will save this version of the file in ~/foo.
[ Rewritten based on the first comment ]
All files in Clearcase, including versions, are available in the virtual directory structure. I don't have a lot of familiarity with static views, but I believe they still go through a virtual fs; they just get updated differently.
In that case, you can just do:
cat File##/main/28
It can get ugly if you also have to find the right version of a directory that contained that file element. We have a PERL script at work that uses this approach to analyze historical changes made to files, and we quickly ran out of command-line space on Windows to actually run the commands!
If File is a Clearcase element, and cat File works, and the view is set correctly, then try:
cat File##/main/28
(note: without the ct shell-- you shouldn't need this if you're already in the view.)
Try typing:
ct ls -l File
If it shows the file with an extended name similar to the above, then you should be able to cat the file using an extended name.
ct shell cat File##version