Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is it possible to write custom expansion hooks in bash, just like what bash does for {a..b}? I want to implement a capability to expand/manipulate square brackets [content] and the content inside that. I want all the existing scripts/commands to work as-is
No, bash does not support this feature.
While it's not inconceivable that a version of bash could be written that allows some sort of custom parsing hooks, [...] would be a bad choice since square brackets are already used as a synonym for the test command and for regular expression bracket expressions (i.e., [ab]cd to match either acd or bcd). You would be hard pressed to define another use for square brackets alone that don't interfere with these existing uses. (Although it's not impossible, as the obsolete $[...] notation for arithmetic expressions shows.)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
One of the ways to write a multi-line string in Ruby is the "here document", or "heredoc", with syntax like:
<<~HEREDOC
My multi-line string
literal goes here!
HEREDOC
My understanding is that any identifier (word) can be used in place of where HEREDOC was used in the above example. (It doesn't have to be the word HEREDOC.)
Is there a documented best practice -- for code readability, and conformity to standards -- for choosing the name to use in a heredoc declaration?
Observations I've made:
The official documentation (as of Ruby v3.0) doesn't seem to advocate any particular best practice. It just states:
You may use any identifier with a heredoc, but all-uppercase identifiers are typically used.
The word SQL seems common when defining a SQL statement -- regardless of the purpose of the statement.
Code examples (including in the official documentation, and in the canonical StackOverflow question on multi-line strings in Ruby linked above) often use HEREDOC, or EOS (presumably meaning "end-of-string" -- even though the identifier appears both at the beginning and end of the string literal).
Sometimes, a word describing the value being stored is used as the heredoc identifier -- as is typically done when declaring a standard variable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am in a process of refactoring some unix shell scripts
and find many inconsistencies and different styles in our code
For example:
somevar="${item1},${item2}"
somevar=${item1}","${item2}
somevar="$item1,$item2"
Is there a coding style guide for unix shell scripts? or a formatter like clang-format for C++
[Edit] Please note I am not asking for personal style preferences or personal opinion! I am looking for an industry standard document, a widely used style guide or a popular tool.
I've worked in a few companies that have their own style guides but most now use Google's style guide. If you don't have a home grown style guide then Google's is good and is published here: https://google.github.io/styleguide/shell.xml
I personally check my shell scripts with the shellcheck plugin for vim but it's available on the web and for other editors. You can use it and get the downloads here: https://www.shellcheck.net/
Since word splitting won't happen in the context of a variable assignment you could just use:
somevar=${item1},${item2}
I personally prefer to use
somevar="${item1},${item2}"
The quotes doesn't hurt and - imo - increase readability.
About ${var} vs. $var. That matters when the variable name may contain an underscore, like "$foo_bar". What does it mean? The variable $foo plus the literal string _bar? Or the expansion of the variable $foo_bar? I would consequently use ${var} to avoid such situations.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Is there (or was there ever) any non-trivial language that allows spaces in its variable names?
I am aware of the language Whitespace, but I'm interested in a language that was actually used for something besides demonstration.
I ask this out of pure curiosity.
In a way, yes. Several languages's variable names are really just keys to a higher-level object. Both Coldfusion and Javascript come to mind. In Javascript, you can write foo=bar, but what you've really said is:
window['foo'] = bar;
You could just as easily write
window['i haz a name'] = bar;
The various scopes in Coldfusion can also be treated as either a (dict|hash|associative array) or a name.
Of course, once you've created a name with whitespace, it's harder to access without using the hash lookup syntax.
TSQL will allow you to use whitespace in table and column names aslong as you have it between square braces [ ]
Theres a fantastic article on just what sql will let you get away with here http://www.sqlservercentral.com/blogs/philfactor/archive/2009/08/14/evil-code.aspx
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
In API documentation, and sometimes even used in discussions here on Stack Overflow, I sometimes see the pound (#) character used instead of the dot (.) as the separator between the class name and the method name. For example:
Settings#maxPageSize
I'm wondering what this usage means, and where it comes from?
Assuming you mean Ruby (which is the first language that I can think of with such conventions), it is explained here:
Why are methods in Ruby documentation preceded by a hash sign?
I've always thought that the distinction is that Settings.maxPageSize seems to imply that you can actually write just that (i.e. that it is a static method), and that the pound is there to denote that it is just a reference to a method, not a piece of code that you can execute.
Although I could be totally wrong about this =)
So for static methods, you could actually reference them Settings.maxPageSize, but for instance methods, you'd have the option of coming up with a new convention, such as Array#sort to denote that something special is going on, or, to achieve the same completeness, you'd have to write
myArray.sort // when myArray is of the type Array
EDIT
Amadan's reply seems to confirm my interpretation, with the exception that Settings.maxPageSize is not used for static methods either; rather, that would be Settings::maxPageSize, and . being reserved entirely for example code, which makes sense to me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Should the name of command line options for a program in a POSIX-style operating system be underscore-style, like
--cure_world_hunger
or maybe some other style?
--cureworldhunger
--cure-world-hunger
--cureWorldHunger
What's most common? What's better style? What's more Bash-friendly (if such a thing exist)?
Underscore is not a good idea, sometimes it gets "eaten" by a terminal border and thus look like a space.
The easiest to read, and most standard way is to use a dash:
--cure-world-hunger
Always hyphens! Let's get a reputed reference: the Gnu style guide:
GNU adds long options to these conventions. Long options consist of
‘--’ followed by a name made of alphanumeric characters and dashes.
Option names are typically one to three words long, with hyphens to
separate words. Users can abbreviate the option names as long as the
abbreviations are unique.
Another problem with underscores is that if the documentation is linked in a HTML document, the link underline will hide the underscore and will confuse the user.
The double dash prefix is a GNU convention I believe. Check out getopt_long(3) man page on the GNU/Linux Operating System.