I am writing a CLI program in GO and need to be able to pass a rather long list of arguments to the main function. At the moment I am using the standard way of passing arguments (space separated values) and then
retrieve 'em using os.Args[index].
So my questions are:
Is there a limit to the number of arguments one can pass?
Is there a limit to the length of a string argument?
Is there any other way of achieving this and if so how?
No, as far as go is concerned. Command line args are parsed into a []string, so at this level it's just a matter of how much memory is available. But, the comments below are correct. Your system will have its own lower limits that you'll hit first.
Same as above.
If you find yourself passing tons for args for every run:
if they don't change much, do they make sense as sane defaults for your flags?
if they don't make sense as defaults, consider moving to reading them from a config file. CSV, YAML, whatever.
Without knowing more, I'd recommend a the config file. They make it easy to track different configs/runs, easier to edit than a long list of cmd line args, and you can always write it so that args on the cmd line overwrite values in the config.
Check out awesome-go for libraries that already do this, specifically under the command-line and configuration sections.
Related
According to the Bash Reference Manual, the Bash scripting language is constituted of 4 distinct subclasses of syntactic elements:
built-in commands (alias, cd)
reserved words (if, function)
parameters and variables ($, IFS)
functions (abort, end-of-file - activated with keybindings such as Ctrl-d)
Apart from reading the manual, I became inherently curious if there was a programmatic way to list out or generate all such keywords, at least from one of the above categories. I think this could be useful in some contexts. Sometimes I wish I could see all the options available to me for what I can write in any given moment, and having that information as data, instead of a formatted manual, is convenient, focused, and can be edited, in case you want to strike out commands you know well, or that are too obscure for now.
My understanding is that Bash takes the input into stdin and passes it to the running shell process. When code is distributed in a production-ready form, it is compiled, so it runs faster. Unlike using a Python REPL, you don’t have access to the Bash source code from within Bash, so it is not a very direct route to write a program that searches through source files to find various defined commands. I mean that if you wanted to list all functions, Python has the dir() function which programmatically looks for function names in the namespace. But I don’t think Bash can do that. I think it doesn’t have a special syntax in its source files which makes it easy to find and identify all the keywords. Instead, they will be found if you simply enter them - like cd will “find” the program cd because $PATH returns the path to that command - but there’s no special way to discover them.
Or am I wrong? Technically, you could run a “brute force” search by generating every combination of symbols of every length and record when you did not get “error: unknown command” as a response.
Is there any other clever programmatic way to do this?
I mean I want to see a list of every symbol or string that the bash
compiler
Bash is not a compiler. It and every other shell I know are interpreters of various languages.
recognises and knows what to do with, including commands like
“ls” or just a symbol like “*”. I also want to see the inputs and
outputs for each symbol, i.e., some commands are executed in the shell
prompt by themselves, but what data type do they return?
All commands executed by the shell have an exit status, which is a number between 0 and 255. This is as close to a "return type" as you get. Many of them also produce idiosyncratic output to one or two streams (a standard output stream and a standard error stream) under some conditions, and many have other effects on the shell environment or operating environment.
And some
require a certain data type to standard input.
I can't think of a built-in utility whose expected input is well characterized as having a particular data type. That's not really a stream-oriented concept.
I want to do this just as a rigorous way to study the language.
If you want to rigorously study the language, then you should study its manual, where everything you describe has already been compiled. You might also want to study the POSIX shell command language manual for a slightly different perspective, which is more thorough in some areas, though what it documents differs in a few details from Bash's default behavior.
If you want to compile your own summary of Bash syntax and behavior, then those are the best source materials for such an effort.
You can get a list of all reserved words and syntactic elements of bash using this trick:
help -s '*' | cut -d: -f1
Or more accurately:
help -s \* | awk -F ': ' 'NR>2&&!/variables/{print $1}'
What is the most idiomatic way to get some form of context to the yacc parser in goyacc, i.e. emulate the %param command in traditional yacc?
I need to parse to my .Parse function some context (in this case including for instance where to build its parse tree).
The goyacc .Parse function is declared
func ($$rcvr *$$ParserImpl) Parse($$lex $$Lexer) int {
Things I've thought of:
$$ParserImpl cannot be changed by the .y file, so the obvious solution (to add fields to it) is right out, which is a pity.
As $$Lexer is an interface, I could stuff the parser context into the Lexer implementation, then force type convert $$lex to that implementation (assuming my parser always used the same lexer), but this seems pretty disgusting (for which read non-idiomatic). Moreover there is (seemingly) no way to put a user-generated line at the top of the Parse function like c := yylex.(*lexer).c, so in the many tens of places I want to refer to this variable, I have to use the rather ugly form yylex.(*lexer).c rather than just c.
Normally I'd use %param in normal yacc / C (well, bison anyway), but that doesn't exist in goyacc.
I'd like to avoid postprocessing my generated .go file with sed or perl for what are hopefully obvious reasons.
I want to be able to (go)yacc parse more than one file at once, so a global variable is not possible (and global variables are hardly idiomatic).
What's the most idiomatic solution here? I keep thinking I must be missing something simple.
My own solution is to modify goyacc (see this PR) which adds a %param directive allowing one or more fields to be added to the $$ParserImpl structure (accessible as $$rcvr in code). This seems the most idiomatic route. This permits not only passing context in, but the ability for the user to add additional func()s using $$ParserImpl as a receiver.
I am playing around with a Android Linux kernel. The kernel is the P970 V30B kernel. Available here.I want to find out what a specific cmdline argument does exactly.
I know it's commandline arguments and there's one argument that is included that I can't find what exactly it does. It's not a standard commandline argument (I can't find any documentation on it) and I suspect it's specific to this kernel. I want to find out what that specific cmdline argument does exactly.
The best reference I was able to find on the subject is this. This told me where about it parses the arguments, but it didn't have enough detail for what I wanted to to find out.
I've looked at the source for the commandline parsing, but it jump around alot and I can't find where it actually parses the individual commands.
I'm looking for a way to get where it parses the command argument. I've tried various fgrep commands to look for a string containing the parameter as a starting point, but to no avail.
Any help or pointers on the subject will be greatly appreciated.
See the file cmdline.c
http://lxr.hpcs.cs.tsukuba.ac.jp/#linux/lib/cmdline.c
You have there the functions get_option(), get_options() etc.
They should be used where the actual parameters are read and dispatched.
edit: The actual parsing is in the file main.c
http://lxr.hpcs.cs.tsukuba.ac.jp/#linux/init/main.c
EDITED:
I've wrote code that uses OptionParser to handle command line input gracefully. I am facing two major hits.
Passing an empty switches '-' doesn't give an error. Of course some programs take that as valid, but mine shouldn't.
The program requires two mandatory switches, but it accepts one switch without complaining! e.g. program.ruby -f foo -b bar is the valid input and both switches are :REQUIRED. But providing only one switch passes without problem and this is not the desired behavior.
For the first case I've done this:
opts.on('-', /\A-\Z/) do
$stderr.print "Invalid empty switch"
exit 1
end
It works fine. But is this the proper way of doing it?
For the second case, I've looked around for a solution within the OptionParser.new block but I couldn't find one. e.g.
unless options.foo && options.bar
puts "Error."
exit 2
end
Doing it outside the OptionParser.new block is the normal way?
If you are using OptionParser, then yes, you need to explicitly disallow the empty switch and manually check the required parameters.
However, if you used another tool for option parsing, such as defunkt's gem choice, you could mark options as required and the invalid options (such as the empty switch) would cause the help to be printed and application to exit. I understand that in some cases it makes more sense to use OptionParser, but personally I prefer to use the more convenient tools out there.
Even though making options required is pretty easy one way or the other, I would recommend that you think your API decision through. How many command line utilities do you know, that have required options? There's a reason why command line is usually separated into options and arguments, with the former being usually optional and the latter usually required. I would stick to that established convention.
I think Thor(https://github.com/wycats/thor) can resolve your problem more efficiently.
EDITED:
I've wrote code that uses OptionParser to handle command line input gracefully. I am facing two major hits.
Passing an empty switches '-' doesn't give an error. Of course some programs take that as valid, but mine shouldn't.
The program requires two mandatory switches, but it accepts one switch without complaining! e.g. program.ruby -f foo -b bar is the valid input and both switches are :REQUIRED. But providing only one switch passes without problem and this is not the desired behavior.
For the first case I've done this:
opts.on('-', /\A-\Z/) do
$stderr.print "Invalid empty switch"
exit 1
end
It works fine. But is this the proper way of doing it?
For the second case, I've looked around for a solution within the OptionParser.new block but I couldn't find one. e.g.
unless options.foo && options.bar
puts "Error."
exit 2
end
Doing it outside the OptionParser.new block is the normal way?
If you are using OptionParser, then yes, you need to explicitly disallow the empty switch and manually check the required parameters.
However, if you used another tool for option parsing, such as defunkt's gem choice, you could mark options as required and the invalid options (such as the empty switch) would cause the help to be printed and application to exit. I understand that in some cases it makes more sense to use OptionParser, but personally I prefer to use the more convenient tools out there.
Even though making options required is pretty easy one way or the other, I would recommend that you think your API decision through. How many command line utilities do you know, that have required options? There's a reason why command line is usually separated into options and arguments, with the former being usually optional and the latter usually required. I would stick to that established convention.
I think Thor(https://github.com/wycats/thor) can resolve your problem more efficiently.