So I have a Makefile in which I have the follwoing code that I try to understand:
for file_exe in `find . -name "zip_exe-*"`; do \
./$${file_exe} -d $(UNZIP_PATH)/lib; \
done
As I understand this piece of code will try to find some executable zip and the extract those zip files to a locations. But what puzzles me is how $${file_exe} is working. Why is the double $$ needed? I guess it has something to do with the fact that some bash commands are running from a makefile, but I can't explain to myself why the $$ is needed and a simple $ does not work since this command is running a sub-shell anyway.
Make needs to distinguish whether you want a $ to use as introducing a make-variable reference, such as ${FOOBAR} or as a plain $ passed on to the shell. The make specification (Section Macros) says that to do the latter, you must use $$ which is replaced by a single $ and passed to the shell. In effect, your snippet reads as
for file_exe in `find . -name "zip_exe-*"`; do \
./${file_exe} -d some/unzip/path/lib; \
done
to the shell.
Style note: Iterating over file lists created by backticks is considered bad style, since it may overflow the ARG_MAX limit. Better to read the file names one-by-one with
find . -name "zip_exe-*" | \
while read -r file_exe; do \
./${file_exe} -d some/unzip/path/lib; \
done
Related
If I want to search an LDAP entry from a LDAP server using ForgeRock Directory Server(OpenDJ), the document says in Linux it works like the following.
$ ldapsearch \
--hostname localhost \
--port 1389 \
--baseDn dc=example,dc=com \
"(cn=Abagail Abadines)" \
cn mail street l
If I want to run this command in Windows, it doesn't seem to work.
What do I need to change in this command to run it on Windows's cmd.
It works the same, you just need to use ldapsearch.bat, and use the Windows continuation character (^) instead of \, or put all arguments on a single line.
Also, when reading the documentation, the upper right corner icon allows you to copy the example command to your clipboard.
I figured it out after two hours of trying! I hope this might help someone. In Linux, \ means new line (of course, it also means escape sequence). It created new line. So in Window's cmd mode, just type the whole command without \
Also, even in Linux, typing the whole command without \ seem to work fine without any error. (By putting \ every line somehow didn't work in the middle. )
In Unix/Linux, Windows, and Mac, '/' (slash) and '\' ( backslash ) are confusing a little. So when executing commands or setting paths, gotta watch out.
I'm trying to use the --immediate-submit on a PBSPro cluster. I tried using an in-place modification of the dependencies string to adapt it to PBSPro, similar to what is done here.
snakemake --cluster "qsub -l wd -l mem={cluster.mem}GB -l ncpus={threads} -e {cluster.stderr} -q {cluster.queue} -l walltime={cluster.walltime} -o {cluster.stdout} -S /bin/bash -W $(echo '{dependencies}' | sed 's/^/depend=afterok:/g' | sed 's/ /:/g')"
This last part gets converted into, for example:
-W depend=afterok: /g/data1a/va1/dk0741/analysis/2018-03-25_marmo_test/.snakemake/tmp.cyrhf51c/snakejob.trimmomatic_pe.7.sh
There are two problems here:
How can I get the dependencies string to output job ID instead of the script path? The qsub command normally outputs the job ID to stdout, so I'm not sure why it's not doing so here.
How do I get rid of the space after afterok:? I've tried everything!
As an aside, it would be helpful if there were some option to debug the submission or not to delete the tmp.cyrhf51c directory in .snakemake -- is there some way to do this?
Thanks,
David
I suggest to use a profile for this, instead of trying to find an ad-hoc solution. This will also help with debugging. E.g., there is already a pbs-torque profile available (https://github.com/Snakemake-Profiles/pbs-torque), probably there is not much to change towards pbspro?
What is the difference between these two redirections?
[localhost ~]$ echo "something" > a_file.txt
[localhost ~]$ echo "something" >| a_file.txt
I can't seem to find any documentation about >| in the help.
>| overrides the noclobber option in the shell (set with $ set -o noclobber, indicates that files can not be written over).
Basically, with noclobber, you get an error if you try to overwrite an existing file using >:
$ ./program > existing_file.txt
bash: existing_file.txt: cannot overwrite existing file
$
Using >| will override that error and force the file to be written over:
$ ./program >| existing_file.txt
$
It's analogous to using the -f or --force option on many shell commands.
From the Bash Reference Manual Section "3.6.2 Redirecting Output":
If the redirection operator is >, and the noclobber option to the set builtin has been enabled, the redirection will fail if the file whose name results from the expansion of word exists and is a regular file. If the redirection operator is >|, or the redirection operator is > and the noclobber option is not enabled, the redirection is attempted even if the file named by word exists.
Searching for "bash noclobber" generally brings up articles that mention this somewhere. See this question on SuperUser, this section in O'Reilly's "Unix Power Tools", and this Wikipedia article on Clobbering for examples.
genstrings works well to extract localizable content from .m file as,
find . -name \*.m | xargs genstrings -o en.lproj
But, not working for .swift file as,
find . -name \*.swift | xargs genstrings -o en.lproj
The genstrings tool works fine with swift as far as I am concerned. Here is my test:
// MyClass.swift
let message = NSLocalizedString("This is the test message.", comment: "Test")
then, in the folder with the class
# generate strings for all swift files (even in nested directories)
$ find . -name \*.swift | xargs genstrings -o .
# See results
$ cat Localizable.strings
/* Test */
"This is the test message." = "This is the test message.";
$
I believe genstrings works as intended, however Apple's xargs approach to generate strings from all your project's files is flawed and does not properly parse paths containing spaces.
That might be the reason why it's not working for you.
Try using the following:
find . -name \*.swift | tr '\n' '\0' | xargs -0 genstrings -o .
We wrote a command line tool that works for Swift files and merges the result of apples genstrings tool.
It allows for key and value in NSLocalizedString
https://github.com/KeepSafe/genstrings_swift
There's an alternative tool called SwiftGenStrings
Hello.swift
NSLocalizedString("hello", value: "world", comment: "Hi!")
SwiftGenStrings:
$ SwiftGenStrings Hello.swift
/* Hi! */
"hello" = "world";
Apple genstrings:
$ genstrings Hello.swift
Bad entry in file Hello.swift (line = 1): Argument is not a literal string.
Disclaimer: I worked on SwiftGenStrings.
There is a similar question here:
How to use genstrings across multiple directories?
find ./ -name "*.m" -print0 | xargs -0 genstrings -o en.lproj
The issue I was having with find/genstrings was twofold:
When it reached folder names with spaces (generated by the output of find), it would exit with an error
When it reached the file where I had my custom routine defined, it was giving me an error when trying to parse my actual function definition
To fix both those problems I'm using the following:
find Some/Path/ \( -name "*.swift" ! -name "MyExcludedFile.swift" \) | sed "s/^/'/;s/$/'/" | xargs genstrings -o . -s MyCustomLocalizedStringRoutine
To summarize, we use the find command to both find and exclude your Swift files, then pipe the results into the sed command which will wrap each file path in quotes, then finally pipe that result into the genstrings command
Xcode now includes a powerful tool for extracting localizations.
Just select your project on the left then Editor menu >> Export localizations.
You'll get a folder with all the text in your files as well as the Localizable.strings and InfoPlist.strings
More details here:
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html
I am trying to grep for the .dat string in all my *.mk files using the below command. I am wondering if this is right, because it doesn't give me any output.
find . -name "*.mk" | grep *.dat
No it's not right, there are a couple of issues: 1) you seem to be supplying grep with a glob pattern, 2) the pattern is not quoted and will be expanded by the shell before grep ever sees it, 3) you're grep'ing through filenames, not file contents.
To address 1), use Basic Regular Expression, the equivalent here would be .*\.dat or just .dat. 2) is a matter of using single or double-quotes. 3) find returns filenames, so if you want grep to operate on each of those files either use the -exec flag for find or use xargs. All these taken together:
find . -name '*.mk' | xargs grep '.dat'
Use Find's Exec Flag
You don't really need a pipeline here, and can bypass the need for xargs. Use the following invocation to perform a fixed-string search (which is generally faster than a regex match) on each file found by the standard find command:
find . -name '*.mk' -exec grep -F .dat {} \;
If you're using GNU find, you can use this syntax instead to avoid the process overhead of multiple calls to grep:
find . -name '*.mk' -exec grep -F .dat {} +
Use xargs:
find . -name "*.mk"| xargs grep '\.dat'
Using exec option in find command this way:
find . -name "*.mk" -exec grep ".dat" \{\} \;