I was looking through similar questions, but this does not quite answer my question
How to escape "${}" in cloudformations "Fn::Sub"
I have a subsection of
AWS::CloudFormation::Init:
commands:
somecommandwithargs -a $aws/something/somethingelse
Here the cloudformation init is evaluating $aws to a blank string since its interpreting it as a variable.
I want to keep it EXACTLY as $aws/something/somethingelse
I cannot find the documentation in CFN docs that states how to escape $ symbols in this situation.
I'm pretty sure it's not evaluated by CloudFormation, as it only processes the !Sub function. Dollar sign is nothing special in YAML, as it has no processing logic, it's just a data structure.
It's probably being properly saved as a launch configuraiton but then, at runtime evaluates to blank string.
Related
I was writing some Perl code in vim and accidentally typed a single quote character in a variable name and noticed that it highlighted it in a different color than normal single quoted strings.
I thought that was odd, so I wrote a small test program (shown above) and tried to run it to see how Perl would handle it and I got this error:
"my" variable $var::with::apostrophes can't be in a package
What exactly is going on here? Are there situations where single quotes in variable names are actually valid? If so, what meaning do single quotes have when used in this context?
The single quote is the namespace separator used in Perl 4, replaced by the double colon :: in Perl 5. Because Perl is mostly backwards compatible, this still works. It's great for golfing, but not much else.
Here's an article about it on perl.com that doesn't explain it.
I've just noticed a pattern (in git and the CommandLineParser lib for .NET) for verb-style command arguments, and wondering if someone can confirm:
myprog dothis -a "someArg"
-a
--arg
What's the difference between the single-dash-prefix and the double-dash-prefix? Is the single dash prefix always for a single-letter argument specifier, where a double dash prefix always for a "long name" of the argument?
Is there a formal convention somewhere that drives this, or is it a generally accepted informal practice? (or am I just making something of nothing?)
Just curious... the I had never noticed the pattern in git and the CommandLineParser docs are pretty thin and some blog post or another implicated the convention.
(for that matter... what's this style of verb/args even called? I can't seem to find much of anything on it)
From the wikipedia: https://en.wikipedia.org/wiki/Command-line_interface
Option conventions in Unix-like systems
In Unix-like systems, the ASCII hyphen-minus begins options; the new
(and GNU) convention is to use two hyphens then a word (e.g. --create)
to identify the option's use while the old convention (and still
available as an option for frequently-used options) is to use one
hyphen then one letter (e.g. -c); if one hyphen is followed by two or
more letters it may mean two options are being specified, or it may
mean the second and subsequent letters are a parameter (such as
filename or date) for the first option.
Two hyphen-minus characters without following letters (--) may
indicate that the remaining arguments should not be treated as
options, which is useful for example if a file name itself begins with
a hyphen, or if further arguments are meant for an inner command (e.g.
sudo). Double hyphen-minuses are also sometimes used to prefix "long
options" where more descriptive option names are used. This is a
common feature of GNU software. The getopt function and program, and
the getopts command are usually used for parsing command-line options.
There is posix convention and getopt
But it's not always the case, e.g. java and find.
See also:
https://golang.org/pkg/flag/
http://docs.oracle.com/javase/8/javafx/api/javafx/application/Application.Parameters.html
In many environments, variable substitution syntax provides for substituting or testing the final value of the variable.
From bash ${foo#t*is}, for instance, is delete regex t*is in the variable.
Is there anything like this available in eclipse?
Specifically, the variables that the framework uses to control and invoke the underlying tools - the ones you see when you list system variables, environment variable, build environment variables, etc.
Accessing these for use in command line invocations is ${VARIABLE_NAME}, and there is a syntax for modifying them - I have seen ${PROJECT_NAME:MyProject} for example.
The question concerns the documentation and full capability of this ability.
I am using atlassian-cli-3.8.0, and attempting to run the following command after successfully running confluence --action getServerInfo.
confluence --action getPage --title Foo
However, this command fails with the following error message.
This function requires a non-blank value for parameter: space
In the documentation here, the only description for the option --space is Space Key. That is completely meaningless to me, but I hope that someone who has already struggled with confluence might know better.
What option is supposed to be passed to --space, and what does it mean?
This was incredibly hard to Google for, because the poor choice of names in this parameter.
The Space Key is referring to the unique identifier for what amounts to a directory in the Confluence Wiki. It is generally the word in the URL between the two /, and is documented here.
A typical format for command line arguments is:
myApp --myArg=myValue
What if I want to pass in a set of key value pairs through the command line? Something like:
myApp --myList={arg1=val1;arg2=val2;arg3=val3...}
Since there seems to be no standard for this sort of thing, can anyone provide examples from well-used utilities that have this sort of command line argument input? I poked around some man pages but didn't find any.
Edit: I'm wondering both how the input should be formatted and what the help text might look like.
I think it largely depends on how you parse the arguments in your program.
Here are some examples that the programs accept multiple key-value pair values.
man php:
--define foo[=bar]
-d foo[=bar] Define INI entry foo with value bar
man git:
-c <name>=<value>
Pass a configuration parameter to the command. The value given will
override values from configuration files. The <name> is expected in
the same format as listed by git config (subkeys separated by
dots).
For both, one can pass multiple -d or -c arguments to the programs which gives you the ability to supply a list of key-value pairs to the programs.
IMO, it's not a big problem having your own style of accepting lists of key-value pairs for your program as long as it works and is well-documented. :)
P.S.: I think this question would be more appropriate be placed on Programmers Stack Exchange rather than on SO. See here and here.
If the app needs so many arguments, I would use a config file instead of passing them in command line:
myApp --config=file.cnf
This approach has the following advantages:
flexibility - you can have a bunch of configs prepared for different invocations, and just use them,
no problems with quoting - it's always painful if command line arguments have spaces, double quotes, <, >, or other special characters,
simplicity - you control the config file format, it can be for example INI, JSON, XML etc. It's easy to create it and as easy to parse as parsing command line -- if not easier,
security - if any argument may be sensitive, it's not visible from tools displaying command line arguments.