Is there any way to have two mutually exclusive options with Thor? For example, I need to provide an option of a list of something. I might have an option -l ent1 ent2 ent3 ent67, and I might have an option -f which I pass a file with contents ent1 ent2 ent3 ent67. Can these two options be made mutually exclusive with Thor without writing extra processing code in the method?
I haven't found a built-in way to do this, but you could accomplish it with your own simple check. Here's an example Thor command that does what you want.
desc "command", "A command that does something."
option :list, aliases: 'l', type: :array
option :file, aliases: 'f'
def list
if options[:list] && options[:file]
puts "Use only one, --list(-l) or --file(-f)"
exit(0)
end
# Place the functions of the command here
end
Hope this helps!
Related
Suppose I have some program called "combine" that takes input of "red", "green" and "blue"-type files to produce an output file (let's say "color.jpg")... BUT the number of each type is arbitrary. Let's also suppose that there's no way to determine what type the file is except through how the user classifies them. What do people usually do in this case?
For instance, on the command line, some of the approaches might be:
command red1,red2,red3 green1,green2 blue1 color.jpg
This comma-approach breaks down if commas can appear in the filenames. It's the approach I like the most though. Another idea would be
command "red1 red2 red3" "green1 green2" "blue1" color.jpg
but this approach also has trouble with spaces in names.
I could also require ASCII files containing lists giving the files of each type:
command redlist greenlist bluelist color.jpg
but this requires lugging around extra files.
Further ideas? Is there a standard LINUX way of doing this?
The standard way would be this:
command --red red1.jpg --red red2.jpg --blue blue1.jpg
With short options:
command -r red1.jpg -r red2.jpg -b blue1.jpg
With bash shorthand:
command -r={red1,red2}.jpg -b blue1.jpg
(The above gets expanded by the shell so it looks like the previous invocation.)
Doing things this way avoids arbitrary limitations like "no commas in filenames" and also makes your program more interoperable with standard *nix utilities like xargs and so on.
Another way is accepting:
command -r redfile1 redfile2 -b bluefile1 blue2 blue2 -g green1
so that:
command -r red* -b blue* -g green*
is possible.
As we are having many components , I am trying to describe all the baselines using following command
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB
It provides output like follows
"Build 13"
master replica: My_PVOB#\My_PVOB
owner: Admin
group: ABC
stream:Components_Integration#\My_PVOB
component: Baselines#\My_PVOB
label status: No Versions to Label
change sets:
promotion level: INITIAL
depends on:
Baseline_2.1.0.13.8206#\My_PVOB (Comp1#\My_PVOB)
Baseline_2.1.0.13.433#\My_PVOB (Comp2#\My_PVOB)
Baseline_2.1.0.13.423#\My_PVOB (Comp3#\My_PVOB)
Baseline_2.1.0.13.3763#\My_PVOB (Comp4#\My_PVOB)
Actually i want to get contents only below depends on: ( Want to get Just following contents)
Baseline_2.1.0.13.8206#\My_PVOB (Comp1#\My_PVOB)
Baseline_2.1.0.13.433#\My_PVOB (Comp2#\My_PVOB)
Baseline_2.1.0.13.423#\My_PVOB (Comp3#\My_PVOB)
Baseline_2.1.0.13.3763#\My_PVOB (Comp4#\My_PVOB)
How to omit the remaining information?
From the fmt_ccase man page:
%[depends_on]Cp
(UCM baselines) The baselines that the composite baseline directly depends on
So for a composite baseline:
cleartool descr -fmt "%[depends_on]Cp" baseline:aBaseline#\apvob
could do the trick, except it will print only the dependent baselines on one line, each name separated by space, and without their associated component name.
So you need to parse that output, and for each baseline name, do a:
cleartool descr -fmt "%[component]Xp" baseline:aBaseline#\apvob
(Or, if your naming convention for baselines allows for it, a simple:
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB | grep Baseline_
would be easier!)
Actually, the OP samselvaprabu took the last proposition to grep what he needed from the initial output. His grep is better than my proposal, because it doesn't depend on the Baseline naming convention, but on the PVob name of said baselines:
I am using windows so your last(simple) command gave me the idea.
Following command works in Dos
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB | find "#\My_PVOB)"
Read "fmt_ccase" manual, you'll find it over there:
cleartool man fmt_ccase
I know one awkward solution for this taks will be :
first use ct ls to get the entire version info of the file
and pipe the version info to a parsing script to actually get the labels of the file .
But I guess ClearCase should have a "build in" solution for this task without support from any external scripts.
Please help me if you happen to know a "build in" solution for the task.
Thanks in advance.
fmt_ccase contains all the format-string for various ClearCase elements.
For a version of a file, you can:
cleartool descr -fmt "%l\n" /path/to/a/version
%l
Labels: For versions, all attached labels; the null string otherwise.
Labels are output as a comma-separated list, enclosed in parentheses.
A <SPACE> character follows each comma.
Variants:
%Cl
Max labels: Specify the maximum number of labels to display with the max-field-width parameter (see Specifying field width).
If there are more labels, "..." is appended to the output.
If no max-field-width is specified, the maximum default value is 3.
%Nl
No commas: Suppress the parentheses and commas in label list output;
separate labels with spaces only.
So the result can be:
Labels: (Rel3.1C, Rel3.1D, Rel3.1E)
Labels without commas or parens: Rel3.1C Rel3.1D Rel3.1E
In both case, you still need to parse the result, but at least the output can contain only the labels, as in:
Rel3.1C Rel3.1D Rel3.1E
onaclov2000 adds (from the comments):
The only problem with this is that you are grabbing the label on the specific version of the file.
Given that branches etc can exist, we'll need to be able to get ALL labels on a file.
If you use version tree graphical and select tools -> "locate" you can see ALL the labels attached to that file.
Is there a common command in cleartool that will return the results of "locate", or "contents"?
The lsvtree (graphical version tree) does display the labels of all the versions of the element currently seen by the view when you click "Label Name"
That being said, there does not seem to be a "built-in" solution and some parsing is involved:
For instance (which is a bit shorter than the OP version but still based on a cleartool ls):
ct ls -l addon.xml##|grep version|gawk "{gsub(/^version.*##\\\\/,\"\",$0) ; gsub(/ \ [.*/,\"\",$0); print $0}"
(GnuWin32 syntax)
or, only with a dynamic view:
cd m:/myView/path/to/addon.xml##
# list all files, not directories: the files are the labels
dir /B /A-D
The IBM article "Additional examples of the cleartool find command" is a great source for find query.
To expand on the "lsvtree" bit mentioned by VonC in his answer, you have:
To find all elements with any label:
Windows:
cleartool find . -type f -exec "cleartool lsvtree -a %CLEARCASE_PN%" | findstr
"("
./hello.c##/main/1 (LABEL100, LABEL99, LABEL98, LABEL97)
./foo.xml##/main/BR1/1 (REL2)
./bar.o##/main/1 (REL1)
UNIX/Linux:
cleartool find . -type f -exec 'cleartool lsvtree -a $CLEARCASE_PN' | grep "("
./hello.c##/main/1 (LABEL100, LABEL99, LABEL98, LABEL97)
./foo.xml##/main/BR1/1 (REL2)
./bar.o##/main/1 (REL1)
That finds only labels for versions currently selected in the view, but you could reuse the lsvtree part to grep all versions of a file with labels.
I'm looking for examples of specifying files in a tree structure, for example, for specifying the set of files to search in a grep tool. I'd like to be able to include and exclude files and directories by name matches. I'm sure there are examples out there, but I'm having a hard time finding them.
Here's an example of a possible syntax:
*.py *.html
*.txt *.js
-*.pyc
-.svn/
-*combo_*.js
(this would mean include file with extensions .py .html .txt .js, exclude .pyc files, anything under a .svn directory, and any file matching combo_.js)
I know I've seen these sorts of specifications in other tools before. Is this ringing any bells for anyone?
There is no single standard format for this kind of thing, but if you want to copy something that is widely recognized, have a look at the rsync documentation. Look at the chapter on "INCLUDE/EXCLUDE PATTERN RULES."
Apache Ant provides 'ant globs or patterns where:
**/foo/**/*.java
means "any file ending in '.java' in a directory which includes a directory named 'foo' in its path" -- including ./foo/X.java
In your example syntax, is it implicitly understood that there's an escaping character so that you can explicitly include a file that begins with a dash? (The same question goes for any other wildcard characters, but I suppose I'd expect to see more files with dashes in their names than asterisks.)
Various command shells use * (and possibly ? to match a single char), as in your example, but they generally only match against a string of characters that doesn't include a path component separator (i.e. '\' on Windows systems, '/' elsewhere). I've also seen such source control apps as Perforce use additional patterns that can match against path component separators. For instance, with Perforce the pattern "foo/...ext" (without quotes) will match all files under the foo/ directory structure that end with "ext", regardless of whether they are in foo/ itself or in one of its descendant directories. This seems to be a useful pattern.
If you're using bash, you can use the extglob extension to get some nice globbing functions. Enable it as follows:
shopt -s extglob
Then you can do things like the following:
# everything but .html, .jpg or ,gif files
ls -d !(*.html|*gif|*jpg)
# list file9, file22 but not fileit
ls file+([0-9])
# begins with apl or un only
ls -d +(apl*|un*)
See also this page.
How about find in unixish environments?
Find can, of course, do more than build a list of files, but that is one of the common ways it is used. From the man page:
NAME
find -- walk a file hierarchy
SYNOPSIS
find [-H | -L | -P] [-EXdsx] [-f pathname] pathname ... expression
find [-H | -L | -P] [-EXdsx] -f pathname [pathname ...] expression
DESCRIPTION
The find utility recursively descends the directory tree for each
pathname listed, evaluating an expression (composed of the
primaries''
andoperands'' listed below) in terms of each file in the tree.
to achieve your goal I would write something like (formatted for readability):
find ./ \( -name *.{py,html,txt,js,pyc} -or \
-name *combo_*.js -or \
\( -name *.svn -and -type d\)\) \
-print
Moreover there is a idomatic pattern using xargs which makes find suitable for sending the whole list so constructed to an arbitrary command as in:
find /path -type f -print0 | xargs -0 rm
find(1) is a fine tool as described in the previous answer but if it gets more complicated, you should consider either writing your own script in any of the usual suspects (Ruby, Perl, Python et al.) or try to use one of the more powerful shells such as zsh which has a ** globbing commands and you can specify things to exclude. The latter is probably more complicated though.
You might want to check out ack, which allows you to specify file types to search in with options like --perl, etc.
It also ignores .svn directories by default, as well as core dumps, editor cruft, binary files, and so on.
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