Im trying to copy a file in docker with below format
database-20.2.1.zip
I have tried using something like below, but it does not seems to work
COPY databse-+([0-9]).+([0-9]).+([0-9]).zip /docker-entrypoint-initdb.d/database.zip
Is this something that can be done in docker copy ?
Dockerfile COPY uses shell globs, not regular expressions. The actual implementation uses the Go filepath.Match syntax. That syntax doesn't allow some of the combinations that regular expressions do: you can match any single digit [0-9], or any number of characters *, but not any number of digits.
Depending on how strict you want to be about what files you'll accept and how consistent the filename format is, any of the following will work:
COPY database-[0-9][0-9].[0-9].[0-9].zip ./database.zip
COPY database-*.*.*.zip ./database.zip
COPY database-*.zip ./database.zip
In all cases note that the pattern can match multiple files in the build context. If the right-hand side of COPY is a single file name (not ending with /) but the glob matches multiple files you will get a build error. In this case that's probably what you want.
Related
I'd like to write an app, my_app, that takes a list of named options and a list of filenames from the cmdline, e.g.,
% my_app --arg_1 arg_1_value filename_1 filename_2
The filenames are the last args and are not associated with any named options.
From the cmdline parsers, e.g., flag in Golang, that I've worked, it seems that the parsers will only extract the args that are configured, and that I'd need to identify the list of filenames manually by walking thru the original argv[] list.
I'd like to ask if there are parsers (or their options that I may have overlooked) that can also extract those filenames, or they only return the unprocessed args, and therefore, I could assume that these are the filenames.
The Golang flag module makes the trailing arguments available as the slice flag.Args, which is the trailing part of os.Args.
That's a pretty typical way for command-line argument parsers to work, although the details will vary according to language. The standard C library argument parser, fir example, provides the global optind, which is the index in argv of the first non-flag argument.
I want to run a set of Bazel targets. My BUILD file look like this
load("#rules_java//java:defs.bzl", "java_binary")
java_binary(
name = "run_me",
srcs = glob(["src1/main/java/com/example/*.java"]),
tags = ["java", "good"],
)
java_binary(
name = "me_also",
srcs = glob(["src2/main/java/com/example/*.java"]),
tags = ["java", "good"],
)
java_binary(
name = "do_not_run_me",
srcs = glob(["src3/main/java/com/example/*.java"]),
tags = ["java", "bad"],
)
I want to run all the targets tagged as "good". I'm hoping to be able to do something like
bazel query 'tags(["good"], //...)'
I don't see the ability to query for tags in the documentation. I do see attr, so I tried
bazel query 'attr(tags, "\[good\]", //...)'
But that doesn't work. I assume because
List-type attributes (such as srcs, data, etc) are converted to strings of the form [value1, ..., valuen], starting with a [ bracket, ending with a ] bracket and using ", " (comma, space) to delimit multiple values
I am able to make it work with an exact match,
bazel query 'attr(tags, "\[good, java\]", //...)'
However, notice that
The ordering of the list swapped ("\[java, good\]") doesn't get any results). I'm not sure if it's alphabetizing or if it's putting them in a hash-set. But it means the ordering isn't reliable.
I don't want to have to list all the tags. I want to be able to run all the "good" targets even if some are also tagged "slow" or "local".
Can I use tags for this task? Are tags really just intended for tests? (The test_suite is the reason I thought to use tags in the first place.)
If by "run a set of Bazel targets" you mean bazel run, you can use --build_tag_filters for this:
https://docs.bazel.build/versions/3.2.0/command-line-reference.html#flag--build_tag_filters
Note however that bazel run supports running only 1 executable target at a time.
If you want to run many binaries in a single call, you'll need to continue to pursue bazel query.
The attr() filter accepts a regular expression, so to get around the problem of tags being in arbitrary order, you can do something like:
bazel query "attr(tags, '\\bgood\\b', //...)"
(where \b is the word boundary matcher)
If you have multiple tags, you can use intersect:
bazel query "attr(tags, '\\bgood\\b', //...) intersect attr(tags, '\\balso-good\\b', //...)"
That will give you the list of targets to run, then you can do something like:
targets=$(bazel query "attr(tags, '\\bgood\\b', //...)")
bazel build ${targets[#]}
for target in ${targets[#]}; do
bazel run $target &
done
bazel run will build the targets before running them, and bazel will wait on previous invocations of itself in the same workspace[1]. So to get the binaries to run in parallel (if that's something you want), the example builds all the targets before running them. (bazel won't block subsequent invocations of itself once the binary is running)
There's also another idea that seems nicer, which is to have an sh_binary which depends on all the binaries you want to run, and the sh_binary script simply runs them. You would then be able to do bazel run on that single sh_binary. The problem with that is you'd have to list each binary you want to run in the data attribute of the sh_binary, because it's not possible to create dependencies in a BUILD file using a query (despite there being a genquery rule -- that just outputs the results of the query to a file).
[1] unless you have separate output bases using --output_base for the different invocations
I'm still learning how PATH works, what exactly is echo $PATH's output meant to be? What do they tell us?
What exactly is echo $PATH's output meant to be?
The current path.
What do the last two entries tell you?
The last two directories on your path.
In other words, it's unclear what you're asking. Do you not know what a path is? Are you asking what a particular sequence of special characters mean in the context of a path? What is the explicit path you're asking about?
$PATH variable is simply a list of paths that your system automatically checks whenever you run a command on, say your bash terminal.
PATH is a colon : (Unix-like) or semi-colon ; (Windows) separated list.
Whenever you run a command like ls -lrt, your system looks for the definition of the command (or function) ls. So the definition of the PATH variable being established, we can answer your two questions:
what exactly is echo $PATH's output meant to be
The $PATH's output provides a list of paths.
What do the last two entries of PATH tell you?
PATH is list is of all the paths where your system will look for a command. So the last 2 entries tell you the last 2 paths out of the list.
I'm setting up TFS 2015 on-prem and I'm having an issue on my last build step, Publish Build Artifacts. For some reason, the build agent appears to be archiving old binaries and I'm left with a huge filepath:
E:\TFSBuildAgent\_work\1a4e9e55\workspace\application\Development\project\WCF\WCF\obj\Debug\Package\Archive\Content\E_C\TFSBuildAgent\_work\1a4e9e55\workspace\application\Development\project\WCF\WCF\obj\Debug\Package\PackageTmp\bin
I'm copying the files using the example minimatch pattern to begin with:
**\bin
I'm only testing at the moment so this is not a permanent solution but how can I copy all binaries that are in a bin folder but not a descendant of obj?
From research I think that this should work, but it doesn't (It doesn't match anything):
**!(obj)**\bin
I'm using www.globtester.com to test. Any suggestions?
On a separate note, I'll look into the archiving issue later but if anyone has any pointers on it, feel free to comment. Thanks
In VSTS there are two kinds of pattern matching for URLs that are built-in to the SDKs. Most tasks nowadays use the Minimatch pattern as described in Matt's answer. However, some use the pattern that was used by the 1.x Agent's Powershell SDK. That format is still available in the 2.x Agent's Powershell SDK by the way.
So that means there are 5 kinds of tasks:
1.x agent - Powershell SDK
2.x agent - Node SDK
2.x agent - Powershell 1 Backwards compatibility
2.x agent - Powershell 3 SDK - Using find-files
2.x agent - Powershell 3 SDK - Using find-match
The ones in bold don't Minimatch, but the format documented in the VSTS-Task-SDK's find-files method.
The original question was posted in 2015, at which point in time the 2.x agent wasn't yet around. In that case, the pattern would, in all likelihood, be:
**\bin\$(BuildConfiguration)\**\*;-:**\obj\**
The -: excludes the items from the ones in front of it.
According to Microsoft's documentation, here is a list of
file matching patterns you can use. The most important rules are:
Match with ?
? matches any single character within a file or directory name (zero or one times).
Match with * or +
* or + matches zero or more characters within a file or directory name.
Match with # sign
# matches exactly once.
Match with Brackets (, ) and |
If you're using brackets with | it is treated as a logical OR, e.g. *(hello|world) means "Zero or more occurrances of hello or world"
Match with Double-asterisk **
** recursive wildcard. For example, /hello/**/* matches all descendants of /hello.
Exclude patterns with !
Leading ! changes the meaning of an include pattern to exclude. Interleaved exclude patterns are supported.
Character sets with [ and ]
[] matches a set or range of characters within a file or directory name.
Comments with #
Patterns that begin with # are treated as comments.
Escaping
Wrapping special characters in [] can be used to escape literal glob characters in a file name. For example the literal file name hello[a-z] can be escaped as hello[[]a-z].
Example
The following expressions can be used in the Contents field of the "Copy Files" build step to create a deployment package for a web project:
**\?(.config|.dll|*.sitemap)
**\?(.exe|.dll|.pdb|.xml|*.resx)
**\?(.js|.css|.html|.aspx|.ascx|.asax|.Master|.cshtml|*.map)
**\?(.gif|.png|.jpg|.ico|*.pdf)
Note: You might need to add more extensions, depending on the needs of your project.
The Lua specs say about package.config (numbering added by me):
The first line is the directory separator string. Default is '\' for Windows and '/' for all other systems.
The second line is the character that separates templates in a path. Default is ';'.
The third line is the string that marks the substitution points in a template. Default is '?'.
The fourth line is a string that, in a path in Windows, is replaced by the executable's directory. Default is '!'.
The fifth line is a mark to ignore all text before it when building the luaopen_ function name. Default is '-'.
My paraphrasing:
Absolutely clear (example for Windows/other systems makes it fool proof)
There can be multiple paths in a path string. They are separated by this symbol (; by default).
Wherever Lua finds this character in the path string (? by default), it will replace it with the module name supplied to the require or package.searchpath functions and check whether that file exists.
So far, so good, but the last two lines aren't entirely clear to me.
Why does it say "in a path in Windows"? Does that mean on other platforms, this doesn't have any significance? If so, why?
It took me a while to make sense of this, but eventually another part of the specs gave me a hint:
The name of this C function is the string "luaopen_" concatenated with a copy of the module name where each dot is replaced by an underscore. Moreover, if the module name has a hyphen, its prefix up to (and including) the first hyphen is removed. For instance, if the module name is a.v1-b.c, the function name will be luaopen_b_c.
So is this symbol (- by default) intended to make different versions of a library available at the same time – potentially with an unprefixed symlink to the newest version so that the same library would be accessible on two paths (i.e. under two module names), but with only one C symbol name?
4: Applications for Linux have libraries installed system-wide; however, for Windows, libraries can be installed in the current directory.
5: Versioning and project forking, I believe, would be the reason behind this.