The Bazel genquery documentation says:
In contrast to the command line and other places in BUILD files, labels here are resolved relative to the root directory of the workspace. For example, the label :b in this attribute in the file a/BUILD will refer to the target //:b.
This means, in the pkg package I have to write //pkg:b instead of b or :b. However, this yields to user confusion, if the genquery is wrapped in a macro: The user must be aware of the implementation to know about the additional requirements, e.g:
my_cc_binary(
name = "app",
deps = ["foo", ":bar", "//baz:qux"],
)
If my_cc_binary wraps a genquery (in addition to a cc_binary) that operates on deps, the semantics of the lables change. How to make the specified relative labels absolute in a macro?
Use package_name and repository_name:
def absolute_label(label):
if label.startswith('#') or label.startswith('/'):
return label
if label.startswith(':'):
return '#' + native.repository_name() + '//' + native.package_name() + label
return '#' + native.repository_name() + '//' + native.package_name() + ':' + label
Related
I am using an Excel macro to call up UltraEdit in order to execute a script on some files.
In the Excel macro I write the path that I want the new file to be saved in by the UltraEdit script. Up until this point all work and if I do a write of the value I read in the temporary file I see that I have the correct path.
But when I use the saveAs("^c") the file does not get saved to the path I specified, but instead gets saved to the current directory.
If I use the following code it saves the file properly. But I don't want to hard code the path:
var sPath="H:\\IPEX\\DataFiles\\IPEX_Originals_Cleaned_Files\\"
+ sTransSet
+"_"
+ sDocNum
+ "_"
+ now.getFullYear()
+ month
+ day
+ "-"
+ hours
+ minutes
+ seconds
+ ".txt";
UltraEdit.saveAs(sPath);
This is the code I am trying to fix:
UltraEdit.selectClipboard(1); // switch to user clipboard #1
var sPath=asParameterList[0]
+ sTransSet
+"_"
+ sDocNum
+ "_"
+ now.getFullYear()
+ month
+ day
+ "-"
+ hours
+ minutes
+ seconds
+ ".txt";
UltraEdit.clipboardContent=sPath;
UltraEdit.outputWindow.write("sPath Value After assign= "+sPath);
UltraEdit.saveAs("^c");
The write command shows me the following:
sPath Value After assign=
H:\\IPEX\\DataFiles\\IPEX_Originals_Cleaned_Files\\856_IPEX-155630-2_20190607-152606.txt
Instead of saving the file to directory
H:\\IPEX\\DataFiles\\IPEX_Originals_Cleaned_Files\\
it saves the file to directory
H:\IPEX\DataFiles\Boomi_IPEX_Files
which is the directory of the original file.
I agree with Alexander Pavlov and his analysis of the cause of the issue. The full qualified file name in clipboard is invalid because of having leading newline characters.
And the full qualified file name string contains additionally \\ instead of just \ as directory separator. \\ within a file path is no problem for Windows file system kernel functions in comparison to the newline character which is an invalid character for a file name or path according to Microsoft's documentation Naming Files, Paths, and Namespaces. But the full qualified file name should be nevertheless 100% correct.
These issues should be best fixed in Visual Basic macro in Excel file. In Visual Basic strings the backslash character is not an escape character like in other programming and scripting languages. Therefore the file path must be defined in Visual Basic macro with just \ and not with \\. And leading spaces/tabs/newline characters should be also removed from file path string in Excel macro before copying the full qualified file name to clipboard.
It is of course also possible to use in UltraEdit script following line before saving the new file with full qualified name in clipboard.
UltraEdit.clipboardContent = UltraEdit.clipboardContent.replace(/^\s+/,"").replace(/\\\\/g,"\\");
The first replace removes all leading whitespaces according to Unicode definition and the second replace modifies all occurrences of \\ to just \ in file name string before the fixed full qualified file name is copied back to clipboard.
But there is really no need to use a clipboard as also written by Alexander Pavlov. The invalid full qualified file name string is already stored in a JavaScript String object with the not really good name sPath. A better name for this string variable would be sFullFileName. The UltraEdit function UltraEdit.saveAs() expects a String object as parameter. So it is also possible to use in UltraEdit script:
var sFullFileName = sPath.replace(/^\s+/,"").replace(/\\\\/g,"\\");
UltraEdit.saveAs(sFullFileName);
Note: Replacing all occurrences of \\ by just \ would be wrong for full qualified file name having a UNC path which must start with two backslashes.
Your debug output prints file name on a new line. It seems filename is preceded with a new line symbol. I think it is why it does not work. Try to trim all spaces and new lines from sPath up until the first character.
I've come across the following code and can not understand what operation the double exclamation marks provide. This code-snipet is from a FAKE script used in a CICD system. Microsoft's Symbol and Operator Reference does not list this operator, nor can I find it in FAKE's API Reference.
!! (projectPackagePath + "/*.zip")
|> Seq.iter(fun path ->
trace ("Removing " + path)
ShellExec tfCommand ("delete " + path + " /noprompt")
Another example of usage
let buildLabelFiles =
!!(labelPath ## "*.txt")
The !! operator takes a file pattern and returns a collection of files matching the pattern.
For example, if you want to print all text files in the current folder, you can write:
for file in !! "*.txt" do
printfn "%s" file
If you look at the operator definition in the source code, you can see that it is just an alias for creating a IGlobbingPattern value (see the type definition) that includes files given by the specified pattern. The IGlobbingPattern type implements IEnumerable, so you can iterate over the files, but you can do a couple of other things with IGlobbingPattern such as combining two file sets using ++ or removing some files from a file set using --.
I'm trying to look for specific files in a directory using a pattern
Lets say i have the id of the user - 101
here are my files
101
101_2
101_5
10111
103
10125
101_6
I'm trying to form a regex pattern which only gives me files (101,101_2,101_5,101_6)
I'm trying the below pattern
^101_?\d+$
but it doesnt seem to pick any of the files at all. if i remove the ^.only 101_6 matches for some reason.
EDIT:
I'm using rails/ruby to look for files in the particular directory. so something like
Dir.glob(location).grep("^101_?\d+$")
do something
end
If location isn't the current folder, paths returned by glob will contain dirname and basename :
Dir.glob('./*').select{ |f| File.basename(f) =~ /\A101(_\d+)?\z/ }.each do |f|
puts f
# do something with f
end
Your question isn't particularly clear, but I'm guessing you want to match anything which is 101 followed by an optional underscore and a digit. If so, use the regex ^101_?\d$. If you want 101 followed by either a digit or an underscore and one or more digits, use ^101(_\d+|\d)$
EDIT
As the OP has mentioned in a comment, 101 should also be matched. The updated regex is ^101(?:_?\d)?$
In my DSL, I have something similar to:
x = 14
y = $x + 1
So an element is defined with just its name, but when referred to, some sigil must be added. Any whitespace between the sigil and the name is forbidden when referencing the element.
How can I do this in Xtext, while still allowing cross-reference between these elements?
Because it seems to me that I either have to use two different terminals for this - one to match x and the other to match $x - but then how would the cross-reference mechanism associate them together? Or alternatively, if I define:
ElementRef: '$' [Element|ELEMENT_NAME];
then Xtext will allow whitespace between the sigil and the name, which is illegal in my DSL. I guess an option such as "do not accept whitespace at this point" would be great, but I could not find anything in the Xtext documentation about something like that.
You have to use a datatype rule for the cross-reference token and register a value converter that strips the $ sign.
ElementRef: [Element|ReferenceID];
ReferenceID hidden(): '$' ID;
The value converter is responsible for the conversion between the abstract syntax (the ID) and the concrete syntax ($ID) for your tokens. Please refer to the docs for details.
I need to parse the command shell such as:
cp /home/test /home/test2
My problem is in the correct path parsing.
I defined a rule (I can not use a token as path but I need to define it in the parser):
path : ('/' ID)+;
with
ID: (A.. Z | a.. z) +;
WS: (' ') {$channel = HIDDEN;};
I need to keep the token WS hidden, but this gives me the problem that the 2 paths in this example are considered as a single path.
How can I solve this problem?
Thanks
With a little playing around in ANTLRWorks I was able to get this to work:
commands
: command+ EOF;
command
: (CMD first=path second=path '\n') {System.out.println("Command found, first path:" + $first.text + ", and second path:" + $second.text + "\n");};
path : FILE {System.out.println("file is:" + $FILE.text);};
fragment
ID: ('A'..'Z'|'a'..'z')('A'..'Z'|'a'..'z'|'0'..'9')+;
CMD
: ID;
FILE
: ('/' ID)+;
WS: (' '|'\t'|'\r'|'\n') {$channel = HIDDEN;};
Please notice that I had to create a few more lexer rules and then start putting different parser rules to test. I used a java target and will let you use what ever target you want.
Oh yeah, each command has to be on a separate line because of the '\n' in the command rule.
Ok, based on your comment, how about something like this:
commands
: command+ EOF;
command
: (ID ' ' (path)+ ' ' (path)+ '\n') {System.out.println("Command found:" + $command.text + "\n");};
path :
('/' ID)+ {System.out.println("path is:" + $path.text);};
ID: ('A'..'Z'|'a'..'z')('A'..'Z'|'a'..'z'|'0'..'9')+;
WS: (' '|'\t'|'\r'|'\n') {$channel = HIDDEN;};
Again, I was able to get this working in ANTLRWorks quickly and it appears to work with the cp command listed above. But pesonally I don't like this as much since your path is a list of four tokens and quickly I could not split out easily. So, you might require a rule between command and path (since I would assume your shell command might have some commands that work with files while others work on directories).
I am also hoping the ID and WS lexer rules are what you want.