When I open BashBurn source I se:
mainmenu[7]="$bb_menu_8#check_path"
I don't know what does #check_path mean? And how does it work?
It doesn't mean any special in Bash alone: # is just a part of a string here. It could have a special meaning inside the BashBurn implementation, however.
It looks like it is a part of the translation framework used inside BashBurn. You can search it on your own on GitHub for example.
mainmenu is set in BashBurn.sh, which is then passed as the second argument to the bbmenu function. The function is defined in bbmenu.sh. There is a description of the syntax, including this information:
ALL ITEMS ARE SEPERATED BY AMPERSAND.
All you need to do now is to read the rest of the documentation in the bbmenu.sh file.
Related
How do I pass a variable from a shell script to POV-Ray? My desire would the ability to pass a variable as a command-line argument and then use that value in the .ini file or .pov file
Something like
POV-Ray +pass var=$imageNumber file.pov
And then being able to use var in POV-Ray
I realize that I could edit the .ini and .pov files in the script or use modulus to use the single frame variable as two variables, but both those solutions seem awkward.
I want to generate 1000s of extremely similar scenes. Each scene is exactly the same except that a heightmap uses a different image file as its source. Normally, I would use the animation tools in POV-Ray to generate multiple frames. However, I am already using the animation tools to cycle over a different property in each scene.
For *nix systems, use POV-Ray's file handling system to open the standard-in file in your .pov file
#fopen STDIN "/dev/stdin" read
#read (STDIN, var1, var2)
This will read from the standard-in for a comma separated list of POV literals. However, POV-Ray doesn't handle reading from a pipe; Thus, use herestrings (or heredocuments if you must use only sh compatible syntax) to fill stdin for POV-Ray.
For example, if run in the shell (works for bash):
povray "example.pov" <<<'"hello","world"'
Will fill the variables var1 and var2 from above with the values "hello" and "world" respectively. Note that quotes must be included around each string value in the list. This is because POV wants POV literals in the 'file' we are passing.
If you want to use an .ini file instead, just call the .ini file in place of the .pov file and everything will work as expected.
If you want more or less variable to be passed to the POV file, add or remove variable names from the #read directive and extend or trim the number you are passing to the same length.'
You can also pass shell variables like this. If foo contains "hello" including the quotes, and "example.pov" is expecting one string in the herestring, then
povray "example.pov" <<<$foo
will pass hello to the variable in the #read directive.
Additionally, you can other POV literals than stings, in that case use the relevant POV syntax the that literal type. However, you can't put POV expressions into the herestring. See the wiki page for more information.
As of POV-Ray 3.7 you can now declare constants in the INI file, and therefore the command line, with Declare=MyValue=24. This would be the same as a #declare MyValue=24; in a scene file. The value on the right-hand side must be a constant float value.
see the relevant manual entry
As long as you don't pass fractional values (or use extremely large sequence numbers), you should be able to use this as a component in the file name.
The Rundeck docs give the example of defining a message option (parameter) which can then be referred to by the script in a number of ways, including
echo message=#option.message# ;# replacement token
We use this syntax and it seems fine, but I have no idea what those two #s actually mean to bash; I can't find mention of anything beyond $#, or anything relevant for the "replacement token" in the comment.
Per the docs you linked, that is a "replacement token" handled by Rundeck. That is, Rundeck replaces the #...# before passing the command to bash. Consequently, they don't mean anything to bash :) . Specifically, the docs say:
Inline Script workflow steps that contain a token expansion will be expanded into a temporary file, and the temp file will contain the plaintext option value.
So bash sees the temp file post-expansion, without the #...# sequences and with their values as literal text.
The docs also note that "If the option is blank or unset the token will be replaced with a blank string." Therefore, the whole #...# sequence will disappear if a particular token is not defined.
See also this section on script usage and this section on context variables in the docs.
I've encountered a problem in my bash script.
I need to assign new variables according to files in my folder and assign them a number according to the amount of arguments the script gets (whether it's a script or not).
I'm trying to get a script written like this:
n_${array[*]}=`arg_count ${array[*]}`
while arg_count checks how many parameters a script gets.
for further use, I'm going to change those variables if there's a function with different arguments needed.
Thanks in advance!
In general, you can use the declare builtin to accomplish this, because it is a command whose argument is a string that resembles an assignment.
declare "n_${array[*]}=$(arg_count ${array[*]})"
However, note that unless you set IFS appropriately and the array contents are amenable, the expansion of ${array[*]} isn't going to be a string that forms part of a valid identifier.
You probably want to either use an associative array,
declare -A n
n[${array[*]}]=$(arg_count ${array[*]})
or write your code in a programming language that properly supports data structures.
I'm trying to filter out all file names from an SQLite text dump using Ruby. I'm not very handy/familiar with regex and need a way to read, and write to a file, another dump of image files that are within the SQLite dump. I can filter out everything except stuff like this:
VALUES(3,5,1,43,'/images/e/e5/Folder%2FOrders%2FFinding_Orders%2FView_orders3.JPG','1415',NULL);
and this:
src="/images/9/94/folder%2FGraph.JPG"
I can't figure out the easiest way to filter through this. I've tried using split and other functions, but instead of splitting the string into an array by the character specified, it just removed the character.
You should be able to use .gsub('%2', ' ') the %2 with a space, while quoted, it should be fine.
Split does remove the character that is being split, though. So you may not want to do that, or if you do, you may want to use the Array#join method with the argument of the character you split with to put it back in.
I want to 'extract' the file name from the statements above. Say I have src="/images/9/94/folder%2FGraph.JPG", I want folder%2FGraph.JPG to be extracted out.
If you want to extract what is inside the src parameter:
foo = 'src="/images/9/94/folder%2FGraph.JPG"'
foo[/^src="(.+)"/, 1]
=> "/images/9/94/folder%2FGraph.JPG"
That returns a string without the surrounding parenthesis.
Here's how to do the first one:
bar = "VALUES(3,5,1,43,'/images/e/e5/Folder%2FOrders%2FFinding_Orders%2FView_orders3.JPG','1415',NULL);"
bar.split(',')[4][1..-2]
=> "/images/e/e5/Folder%2FOrders%2FFinding_Orders%2FView_orders3.JPG"
Not everything in programming is a regex problem. Somethings, actually, in my opinion, most things, are not candidates for a pattern. For instance, the first example could be written:
foo.split('=')[1][1..-2]
and the second:
bar[/'(.+?)'/, 1]
The idea is to use whichever is most clean and clear and understandable.
If all you want is the filename, then use a method designed to return only the filename.
Use one of the above and pass its output to File.basename. Filename.basename returns only the filename and extension.
I'm using Sphinx to document a command line utility written in Python. I want to be able to document a command line option, such as --region like this:
**--region** <region_name>
in ReST and then use Sphinx to to generate my HTML and man pages for me.
This works great when generating man pages but in the generated HTML, the -- gets turned into - which is incorrect. I have found that if I change my source ReST document to look like this:
**---region** <region_name>
The HTML generates correctly but now my man pages have --- instead of --. Also incorrect.
I've tried escaping the dashes with a backslash character (e.g. \-\-) but that had no effect.
Any help would be much appreciated.
This is a configuration option in Sphinx that is on by default: the html_use_smartypants option (http://sphinx-doc.org/config.html?highlight=dash#confval-html_use_smartypants).
If you turn off the option, then you will have to use the Unicode character '–' if you want an en-dash.
With
**-\\-region** <region_name>
it should work.
In Sphinx 1.6 html_use_smartypants has been deprecated, and it is no longer necessary to set html_use_smartypants = False in your conf.py or as an argument to sphinx-build. Instead you should use smart_quotes = False.
If you want to use the transformations formerly provided by html_use_smartypants, instead it is recommended to use smart_quotes, e.g., smart_quotes = True.
Note that at the time of this writing Read the Docs pins sphinx==1.5.3, which does not support the smart_quotes option. Until then, you'll need to continue using html_use_smartypants.
EDIT It appears that Sphinx now uses smartquotes instead of docutils smart_quotes. h/t #bad_coder.
To add two dashes, add the following:
.. include:: <isotech.txt>
|minus|\ |minus|\ region
Note the backward-slash and the space. This avoids having a space between the minus signs and the name of the parameter.
You only need to include isotech.txt once per page.
With this solution, you can keep the extension smartypants and write two dashes in every part of the text you need. Not just in option lists or literals.
As commented by #mzjn, the best way to address the original submitter's need is to use Option Lists.
The format is simple: a sequence of lines that start with -, --, + or /, followed by the actual option, (at least) two spaces and then the option's description:
-l long listing
-r reversed sorting
-t sort by time
--all do not ignore entries starting with .
The number of spaces between option and description may vary by line, it just needs to be at least two, which allows for a clear presentation (as above) on the source, as well as on the generated document.
Option Lists have syntax for an option argument as well (just put an additional word or several words enclosed in <> before the two spaces); see the linked page for details.
The other answers on this page targeted the original submitter's question, this one addresses their actual need.