I use OMNeT++ and I have this question about .ini files:
Why do we sometimes use * and sometimes we use ** to set parameters of NED modules?
According to the OMNeT++ Manual (Section 3.6.1)
* means A wildcard for any substring not containing a dot
** means A wildard for any sequence of characters including dots, so it can match multiple path elements
Example:
Lets assume you have the following modules:
aaa.bbb.value and aaa.ddd.value and ccc.bbb.value
**.value = 0 would address all modules, the path before is not important.
aaa.*.value = 0 would address the value element of aaa.bbb.value and aaa.ddd.value. ccc.bbb.value is not addressed because the wildcard is only for the middle substring of the path, as it contains no dots.
Related
My bash script operates with different files located within the same directory and then execute some program for them. Each files match the following pattern where the ${receptor} keyword is always located after the second "_" of the file name. This keyword defines the group of the file.
something_something_${receptor}_repX.pdb
According to the ${receptor}, all files are devided in three groups. So I create a special function which set the name of the prefix and execute all operations in flow only for the files contained this index:
set_receptor () {
#receptor='5r82dim'
#receptor='2zu2dim'
receptor='7dr8dim'
}
set_receptor
for pdb in "${docking_pdb}"/*_${receptor}_*.${lig_ext}; do
pdb_name=$(basename "$pdb" .${lig_ext})
pdb_name="${pdb_name/_rep1}"
echo "Converting ${output}: the system ${pdb_name}
done
This means that each time when I need to switch between different groups I need to uncomment $receptor manually in the set_receptor function. How could I determine $receptor automatically in the workflow in order that my script could be executed only 1 time for any number of groups and determine each group automatically in the begining of FOR loop execution?
If the keyword is always after the second underscore, you can use parameter expansion to extract it:
#!/bin/bash
for pdb in "$docking_pdb"/*_*_*."$lig_ext" ; do
receptor=${pdb##*/} # Remove the path.
receptor=${receptor#*_} # Up to the first underscore.
receptor=${receptor#*_} # Up to the second underscore.
receptor=${receptor%%_*} # Remove everything after the 1st underscore.
...
done
I created a file with square brackets called [id].go but I am unable to build it.
When I run go build "[id].go", I see the the following:
can't load package: package main: invalid input file name "[id].go"
Are there restrictions on Go file names? Specifically, what is not allowed? Please provide documentation if any.
At the time of writing, Go files must begin with one of the following:
0 through 9
a through z
A through Z
. (period)
_ (underscore)
/ (forward slash)
>= utf8.RuneSelf (char 0x80 or higher)
Two or more files in the same folder can't be named equal (case insensitive match)
https://github.com/golang/go/blob/993ec7f6cdaeb38b88091f42d6369d408dcb894b/src/cmd/go/internal/load/pkg.go#L1826-L1835
To be conservative, we reject almost any arg beginning with non-alphanumeric ASCII.
As an example if you try a[id].go as the file name you should be good to go.
As in the above title question, my current working directory contains one directory "a" which contains another directory "b". The correct path to directory "b" is "a\b" (on Windows platform). Assuming that "/" is used as "switch" character I expect function GetFileAttributesA() to give an error for the specified path "a/b". The following documentation says nothing about additional internal path separator conversion.
The question is why GetFileAttributesA() works with unix path separators?
The C++ code is (C++14):
#include <windows.h>
int main()
{
DWORD gfa1 = GetFileAttributesA("a\\b");
DWORD gfa2 = GetFileAttributesA("a/b");
// Both gfa1 and gfa2 are equal to FILE_ATTRIBUTE_DIRECTORY
// I expect the gfa2 to be INVALID_FILE_ATTRIBUTES
return 0;
}
The reason why I would expect function to fail with "a/b" is simple. To simplify I have one function which tells if particular path is a directory for both Linux and Windows system. As long as the function has the same behaviour for slashes and backslashes on Windows I'm forced to add the same behaviour on Linux (separator conversion) or vice-versa (do not allow creating directories with "/" on Windows which is not supported by this function).
Many parts of Windows accept both forward and backward slashes, including nearly all the file API's. Both slashes are reserved characters, and can not appear within a file or directory name.
I am not sure this is detailed in a central place, but for the file API's, the Naming Files, Path, and Namespaces document has this to say:
File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\?\" prefix as detailed in the following sections.
As for:
Assuming that "/" is used as "switch" character
Since on the command line any file or directory path containing a space must be quoted, you can safely split such a path with forward slashes from any switches/parameters on that space character or quotation rules. Similar to how there is no issue with - being in file and directory names, but also used by many programs for command line switches.
I wanted to install gb
The installation steps says to execute the command:
go get github.com/constabulary/gb/...
What does the ... mean in this case?
The ... (ellipsis) tells go get to also fetch the package's subpackages/dependencies.
From go help packages:
An import path is a pattern if it includes one or more "..."
wildcards, each of which can match any string, including the empty
string and strings containing slashes. Such a pattern expands to all
package directories found in the GOPATH trees with names matching the
patterns. As a special case, x/... matches x as well as x's
subdirectories. For example, net/... expands to net and packages in
its subdirectories.
For an example of how you'd use it, check out this answer.
What does the following file path mean?
$(Services_Jobs_Drop_Path)\**\*.config
The variable just holds some path, nothing interesting. I'm a lot more concerned, what the hell the ** mean.
Any ideas?
P.S. The following path is used in msbuild scripts, if it helps.
\**\ This pattern is often used in Copy Task for recursive folder tree traversal. Basically it means that all files with extension config would be processed from the all subdirectories of $(Services_Jobs_Drop_Path) path.
MSDN, Using Wildcards to Specify Items:
You can use the **, *, and ? wildcard characters to specify a group of
files as inputs for a build instead of listing each file separately.
The ? wildcard character matches a single character.
The * wildcard character matches zero or more characters.
The ** wildcard character sequence matches a partial path.
MSDN, Specifying Inputs with Wildcards
To include all .jpg files in the Images directory and subdirectories
Use the following Include attribute:
Include="Images\**\*.jpg"