po::command_line_style::style_t style = po::command_line_style::style_t(
po::command_line_style::unix_style |
po::command_line_style::case_insensitive |
po::command_line_style::allow_long_disguise );
po::store(po::parse_command_line(argc, argv, commandOptions,style), vm);
po::notify(vm);
The command line that I am trying to parse is of the form
-abc abc_value +xyz xyz_value
I would like to configure the boost program options to use both "-" and "+". I read the help and it states that "The allowed character
for short options is also configurable." But I could not figure out how to do it.
Any help will be much appreciated.
The configurability just refers to the following style flags:
allow_dash_for_short
Allow "-" in short options.
allow_slash_for_short
Allow "/" in short options.
You cannot freely choose a short-option leader character.
Related
I want my go program to only accept command line flags with = form.
Those are forms from the flag documentation that are accepted currently:
-flag
--flag // double dashes are also permitted
-flag=x
-flag x // non-boolean flags only
This is what I want my program to accept:
--flag=x
-flag=x
Basically what I want to accomplish: go run . --color=blue "String I wanna color" here len(os.Args[1:]) should be 2.
Running with space: go run . --color blue "String I wanna color" here len(os.Args[1:] should be equal to 3.
I've only been learning programming for few weeks, I hope this question makes sense and has solution.
I read go flag documentation and looked into functions inside flag package to figure out solution, but I couldn't find anything related to my problem expect only boolean flag accepts form with = sign.
In Windows command line, I got the output like this:
{D1AB12B0-B9B5-43A0-98E1-584D790524FE} Kaspersky for Windows
I am looking for a solution to split the above string into variables using } as delimiter.
Any help is appreciated.
Thank you.
Huy
Use .split() or -split with the desired delimiter. It makes an array out of those splitted parts, which you can than use by index and save it into a variable:
$string = '{D1AB12B0-B9B5-43A0-98E1-584D790524FE} Kaspersky for Windows'
$GUID = $string.split('}')[0].substring(1)
$ProductName= $string.split('}')[1].trim()
In my code .substring() and .trim() is just used for formatting purpose.
I have a custom scripting language, that I am attempting to use XTEXT for syntax checking. It boils down to single line commands in the format
COMMAND:PARAMETERS
For the most part, xtext is working great. The only problem I have currently run into is how to handle wanted (or unwanted) white spaces. The language cannot have a space to begin a line, and there cannot be a space following the colon. As well, I need to allow white space in the parameters, as it could be a string of text, or something similar.
I have used a datatype to allow white space in the parameter:
UNQUOTED_STRING:
(ID | INT | WS | '.' )+
;
This works, but has the side effect of allowing spaces throughout the line.
Does anyone know a way to limit where white spaces are allowed?
Thanks in advance for any advice!
You can disallow whitespace globally for your grammar by using an empty set of hidden tokens, e.g.
grammar org.xyz.MyDsl with org.eclipse.xtext.common.Terminals hidden()
Then you can enable it at specific rules, e.g.
XParameter hidden(WS):
'x' '=' value=ID
;
Note that this would allow linebreaks as well. If you don't want that you can either pass a custom terminal rule or overwrite the default WSrule.
Here is a more complete example (not perfect):
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals hidden()
generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"
Model:
(commands+=Command '\r'? '\n')+
;
Command:
SampleCommand
;
SampleCommand:
command='get' ':' parameter=Parameter
;
Parameter:
'{' x=XParameter '}'
;
XParameter hidden(WS):
'x' '=' value=ID
;
This will parse commands such as:
get:{x=TEST}
get:{ x = TEST}
But will reject:
get:{x=TEST}
get: {x=TEST}
Hope that gives you an idea. You can also do this the other way around by limiting the whitespace only for certain rules, e.g.
CommandList hidden():
(commands+=Command '\r'? '\n')+
;
If that works better for your grammar.
I'm using jamplus to build a vendor's cross-platform project. On osx, the C tool's command line (fed via clang to ld) is too long.
Response files are the classic answer to command lines that are too long: jamplus states in the manual that one can generate them on the fly.
The example in the manual looks like this:
actions response C++
{
$(C++) ##(-filelist #($(2)))
}
Almost there! If I specifically blow out the C.Link command, like this:
actions response C.Link
{
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,#($(2:TC)) $(NEEDLIBS:TC) $(LINKLIBS:TC))
}
in my jamfile, I get the command line I need that passes through to the linker, but the response file isn't newline terminated, so link fails (osx ld requires newline-separated entries).
Is there a way to expand a jamplus list joined with newlines? I've tried using the join expansion $(LIST:TCJ=\n) without luck. $(LIST:TCJ=#(\n)) doesn't work either. If I can do this, the generated file would hopefully be correct.
If not, what jamplus code can I use to override the link command for clang, and generate the contents on the fly from a list? I'm looking for the least invasive way of handling this - ideally, modifying/overriding the tool directly, instead of adding new indirect targets wherever a link is required - since it's our vendor's codebase, as little edit as possible is desired.
The syntax you are looking for is:
newLine = "
" ;
actions response C.Link
{
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,#($(2:TCJ=$(newLine))) $(NEEDLIBS:TC) $(LINKLIBS:TC))
}
To be clear (I'm not sure how StackOverflow will format the above), the newLine variable should be defined by typing:
newLine = "" ;
And then placing the carat between the two quotes and hitting enter. You can use this same technique for certain other characters, i.e.
tab = " " ;
Again, start with newLine = "" and then place carat between the quotes and hit tab. In the above it is actually 4 spaces which is wrong, but hopefully you get the idea. Another useful one to have is:
dollar = "$" ;
The last one is useful as $ is used to specify variables typically, so having a dollar variable is useful when you actually want to specify a dollar literal. For what it is worth, the Jambase I am using (the one that ships with the JamPlus I am using), has this:
SPACE = " " ;
TAB = " " ;
NEWLINE = "
" ;
Around line 28...
I gave up on trying to use escaped newlines and other language-specific characters within string joins. Maybe there's an awesome way to do that, that was too thorny to discover.
Use a multi-step shell command with multiple temp files.
For jamplus (and maybe other jam variants), the section of the actions response {} between the curly braces becomes an inline shell script. And the response file syntax #(<value>) returns a filename that can be assigned within the shell script, with the contents set to <value>.
Thus, code like:
actions response C.Link
{
_RESP1=#($(2:TCJ=#)#$(NEEDLIBS:TCJ=#)#$(LINKLIBS:TCJ=#))
_RESP2=#()
perl -pe "s/[#]/\n/g" < $_RESP1 > $_RESP2
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,$_RESP2
}
creates a pair of temp files, assigned to shell variable names _RESP1 and _RESP2. File at path _RESP1 is assigned the contents of the expanded sequence joined with a # character. Search and replace is done with a perl one liner into _RESP2. And link proceeds as planned, and jamplus cleans up the intermediate files.
I wasn't able to do this with characters like :;\n, but # worked as long as it had no adjacent whitespace. Not completely satisfied, but moving on.
Not every command in Vim allows you to add end-of-line comments. Sometimes the " is valid as an argument, so it would be ambiguous. However, if you insert a pipe, the command is ended and you can insert a comment. So you can actually achieve reliable end of line comments in vim thusly:
noremap ' ` |" Use single quote as alternate range key
Neat, right? But the syntax/vim.vim file doesn't recognize this as an end of line comment. How do I tell Vim to recognize this syntax?
I found this in syntax/vim.vim:
syn match vimLineComment +^[ \t:]*".*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
I tried adding something like this to my ~/.vimrc, but there is no effect. VimScript is hard. :/
syntax match vimLineComment '|".*$+'
Any ideas?
you cannot use in-line comments for maps
:h map-comments
you will see:
*map-comments*
It is not possible to put a comment after these commands, because the '"'
character is considered to be part of the {lhs} or {rhs}.
I hope this answers your question.
hack
Okay， you may have good reason to do that.
Only define syn match vimLineComment is not enough, you have to overwrite the vimMapRhs syntax. so these two lines will make |"foo bar highlighted as comment:
syn match vimMapRhs '.*\ze|\s*".*'
syn match vimLineComment '|\s*".*$'
this may change the "comment" highlight, but I don't recommend to do it.
Background
vim 7.3 all platforms
vimscript language (used in vim files)
Problem
The vimscript language supports comments, but end of line comments do not always work predictably, because end of line comments can be mistakenly interpreted by vim as part of the command.
Adding end of line comments is problemmatic in vimscript, because it does not work with all commands.
Solutions
1) use the pipe character :help :bar to create a separate Ex command
this is the solution enumerated by #sidewaysmilk
2) simply add the comment below the relevant vimscript command on the next line
3) use the execute command (see :help :execute )
Pitfalls
Solution 1) is a somewhat unconventional use of the pipe (aka :bar)
Not all commands support the pipe character (see e.g. :help :execute)
Solution 2) may not be desirable for the readability of the vimscript, and it does not directly solve the issue in the OP
searching for this feature on the internet is tricky because it turns up links related to comments in general-purpose programming contexts, unrelated to vimscript
See also
Vim help links (enter these directly into vim Cmdline-mode):
:help vim-script-intro | /comments for some commands
:help :bar
:help Command-line-mode
Web links:
https://en.wikipedia.org/wiki/Vimscript
https://duckduckgo.com/?q=vim+vim-script-intro+comments
+1 fot "This is not "neat" at all":
noremap ' ` |" Use single quote as alternate range key
My preference is to use end of line comment (without adding |) where vimL allows.
The pain point is:
It's hard to remember when vimL allows that. (so some people never uses end of line comment in vimL, which may narrow his choice of formating)
Inspired by the OP, we can utilize the syntax highlight. (But I don't know how to implement yet)
Below is some information which seems to be needed:
Relevant lines in the syntax.vim:
/home/linuxbrew/.linuxbrew/Cellar/neovim/0.6.1/share/nvim/runtime/syntax/syntax.vim
syn region vimString start="^\s*\\\z(['"]\)" skip='\\\\\|\\\z1' end="\z1" oneline keepend contains=#vimStringGroup,vimContinue
syn match vimComment excludenl +\s"[^\-:.%#=*].*$+lc=1 contains=#vimCommentGroup,vimCommentString
syn match vimComment +\<endif\s\+".*$+lc=5 contains=#vimCommentGroup,vimCommentString
syn match vimComment +\<else\s\+".*$+lc=4 contains=#vimCommentGroup,vimCommentString
syn region vimCommentString contained oneline start='\S\s\+"'ms=e end='"'
hi def link vimCommentString vimString
" end of line comment
syn match vimLineComment +^[ \t:]*".*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
hi def link vimLineComment vimComment
syn match vim9LineComment +^[ \t:]\+#.*$+ contains=#vimCommentGroup,vimCommentString,vimCommentTitle
hi def link vim9Comment Comment
syn match vimCommentTitle '"\s*\%([sS]:\|\h\w*#\)\=\u\w*\(\s\+\u\w*\)*:'hs=s+1 contained contains=vimCommentTitleLeader,vimTodo,#vimCommentGroup
hi def link vimCommentTitle PreProc
syn match vimCommentTitleLeader '"\s\+'ms=s+1 contained
syn match vimContinue "^\s*\\"