I am trying to write a Doxygen file filter that lives in a subdirectory that works from Doxyfile on both Windows and Linux.
Doxyfile
/scripts
myfilter
I seem to be unable to specify the path using a forward-slash on Windows unless it is quoted:
"scripts/myfilter"
However, trying to quote the command in Doxyfile does not work.
FILTER_PATTERNS = *.glsl=""scripts/runpython" scripts/doxygen-glslfilter.py"
On Windows, you get an error that implies the quotes don't exist.
'scripts' is not recognized as an internal or external command, operable program or batch file.
Doxygen uses popen() to run these commands and will remove the wrapping quotes around the command, but it does not seem to remove all quotes.
popen() call:
https://github.com/doxygen/doxygen/blob/master/src/definition.cpp#L745
filter name quote strip:
https://github.com/doxygen/doxygen/blob/master/src/util.cpp#L2458
However, the result is the same as if there were no quotes.
Update
I was able to get command logging in Doxygen, and it appears the extra quotes are being stripped in an odd way. You can see how there is a space in front of the command.
Executing popen(` scripts/runpython scripts/doxygen-glslfilter.py "C:/dev/g3d/G3D10/data-files/shader/AlphaFilter.glsl"`)
Update
I submitted a bug report/feature request but I doubt it will be read.
Doxygen Bug Report
The issue was reported to the doxygen project, and they have provided a solution where any '/' in the command is replaced by '\' on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=792846
This was done to resolve a similar issue here:
What is the QHG_LOCATION path relative to for doxygen?
The pull request for the project on github here: https://github.com/doxygen/doxygen/pull/703
When using double quotes within double quotes in a single string, it sees the first double quote as the start string and the next double quote as the end of the string.
So in your example:
""scripts/runpython" scripts/doxygen-glslfilter.py"
The first 2 quotes are seen as open and close, then it sees scripts/runpython as the next command etc.
I do not have the same tool, but these 2 examples will probably sort out your issue.
This example wraps each set in double quotes, and the entire set in single quotes.
FILTER_PATTERNS = *.glsl='"scripts/runpython" "scripts/doxygen-glslfilter.py"'
Where this example wraps the first set in double quotes and the entire set in single quotes.
FILTER_PATTERNS = *.glsl='"scripts/runpython" scripts/doxygen-glslfilter.py'
NOTE!! I am unable to test this as I do not have the same environment as you. I am therefore not sure if the second option will work, as it might also need scripts/doxygen-glslfilter.py in double quotes, I am adding it to the answer regardless.
Related
So I'm trying to use bat scripts to get the information I need for my pipelines.
An example of that is the line below, where "path" is a variable that contains an absolute path to a file or folder.
String dirOutput = bat(script: "dir ${path}", returnStdout: true)
This works well, except when this path has spaces in it. At which point I will have an error.
I have found this answer: https://stackoverflow.com/a/11903788/20011929
But wasn't able to add the double quotes in the script argument.
Any idea how to add the quotes there?
Note: This has been an issue for other scripts as well, not just dir, so I would prefer to find a solution about the quotes and not specifically about the funtionality of the line.
Thanks all
I'm building a shell script (trying to be POSIX compliant) and I'm stuck in an issue.
The script is supposed to receive an URL and do some things with it's content.
myscript www.pudim.com.br/?&args=ok
The thing is, the ampersand symbol is interpreted as a command additive, and giving to my script only the www.pudim.com.br/? part as an argument.
I know that the right workaround would be to surround the URL with quotes but, because I need to use this script several times in a row, I wanted to paste the URL's without having to embrace it with quotes every time.
Is there some way to get the full URL argument, somehow bypassing the ampersand?
Quotes for full URL
Wrapping the URL in quotes will be your only chance. See popular shell utility curl, as it states for its core argument URL:
When using [] or {} sequences when invoked from a command line prompt,
you probably have to put the full URL within double quotes to avoid
the shell from interfering with it. This also goes for other
characters treated special, like for example '&', '?' and '*'.
See also this question and that.
Extra argument(s) for specifying query parameters
You can also pass query parameter (key-value pair) as separate argument. So you can bypass & as separator. See curl's -F option:
-F, --form <name=content>
Read URL from STDIN
If your script allows user interaction you could read the unescaped URL (including metachars as &) from an uninterpreted input-source. See this tutorial.
You can escape just the ampersand; quotes effectively escape every character between them.
myscript www.pudim.com.br/\?\&args=ok # The ? should be escaped as well
There is no solution that lets you avoid all quoting, as & is a shell metacharacter whose unquoted meaning cannot be disabled. The & terminates the preceding command, causing it to be run in a background process; adding some redundant whitespace, you attempt is the same as
myscript www.pudim.com.br/? &
args=ok
Unescaped, the ? will cause the URL to be treated as a pattern to expand. However, it's unlikely the pattern will match any existing file, and bash's default behavior is to treat an unmatched pattern literally. (The failglob option will treat it as an error, and the nullglob option will make the URL disappear completely from the command line, but neither option is enabled by default.)
From the windows command line, I can successfully call my script as follows:
python spot_check.py "stop|CHST SQ_ARRIVAL|2.3" "stop|14 ST_ARRIVAL|2.6" "19:06:28" "19:15:00"
However, if I want to use the VS Code debugger, and I pass the same arguments using the args attribute in launch.json
"args": [
"stop|CHST SQ_ARRIVAL|2.3",
"stop|14 ST_ARRIVAL|2.6" ,
"19:06:28",
"19:15:00",
]
Then I get the following error:
(base) c:\Users\1266143\Desktop\stringlines_ml>cd c:\Users\1266143\Desktop\stringlines_ml && cmd /C "set "PYTHONIOENCODING=UTF-8" && set "PYTHONUNBUFFERED=1" && C:\Users\1266143\AppData\Local\Continuum\anaconda3\python.exe c:\Users\1266143\.vscode\extensions\ms-python.python-2019.11.50794\pythonFiles\ptvsd_launcher.py --default --client --host localhost --port 61850 c:\Users\1266143\Desktop\stringlines_ml\spot_check.py "stop|CHST SQ_ARRIVAL|2.3" "stop|14 ST_ARRIVAL|2.6" 19:06:28 19:15:00"
'CHST' is not recognized as an internal or external command,
operable program or batch file.
The part that reads 'CHST' is not recognized as an internal or external command, operable program or batch file. leads me to believe that the | is being interpreted as a redirect, rather than as a character in a string literal argument, and the space following CHST means CHST is being interpreted as a command. But why would these arguments evaluate differently on the command line than in Visual Studio? How can I ensure that these arguments are passed correctly to my command line application when in debug mode?
These aren't the quotes you're looking for
You require quotes around your arguments, as shown when running the script/program directly on the command-line (i.e. "stop|CHST SQ_ARRIVAL|2.3")
But in the JSON, the first set of quotes will get stripped off when the JSON is interpreted, so the string "stop|CHST SQ_ARRIVAL|2.3" in the JSON becomes just stop|CHST SQ_ARRIVAL|2.3 before it's fed to later processes.
Then all the arguments get fed to the Command Line or Python interpreter, which will look something like this (although it will likely be a huge line with a bunch of debugging flags and such):
c:/mypath/myfile stop|CHST SQ_ARRIVAL|2.3 stop|14 ST_ARRIVAL|2.6 19:06:28 19:15:00
The quotes you thought you had around the arguments no longer exist. This means that the parser interprets the vertical bar symbol as the "Pipe" command, which tell it that the first command is done, and it should take the output of that command and "pipe" it to the command that follows.
So, the parser thinks you told it to:
Run the command c:/mypath/myfile stop
Take the output of that command and pipe it to the command CHST SQ_ARRIVAL
Pipe the output of that command to the command 2.3 stop
etc.
Since it can't find the command CHST with the argument SQ_ARRIVAL, it gives you the error message you are seeing.
The fix is in
If you want the quotes to end up being passed along as a part of the argument you'll need to layer them. How to do this depends on how the JSON interpreter will handle multiple sets of quotes (I'm not sure how it does).
A few things to try:
Use triple quotes: """stop|CHST SQ_ARRIVAL|2.3""" - in some parsers, when it sees the first quote it starts a string, but if it sees 2 quotes in a row after that, it makes them into a quote inside the string, rather than ending it. So the first and last quote start and end the string, while the other two pairs of quotes will be condensed into a quote on the outside of your argument
Use a backslash in front of the quotes inside the JSON string: "\"stop|CHST SQ_ARRIVAL|2.3\"" - in many parsers the backslash character is an "escape" character and any character immediately after it is considered a string literal that will be put directly into the string, even if it is normally a special character.
Use single quotes inside the string: "'stop|CHST SQ_ARRIVAL|2.3'" - Since Python can use either single or double quotes as a string, normally any arguments going to a python interpreter with single quotes will also be considered a string. However, I'm not sure the arguments will get that far in this case, they will probably be interpreted by the shell first, which likely will not consider single quotes to be the start of a string (but you never know for sure..).
Which method works may depend on what shell you are using (i.e. Windows command prompt, Powershell, Git Bash, sh, c-sh, etc.). Each of them could handle command line interpretation of strings differently.
If none of these works, knowing the root cause, a further search should turn up the answer. Good luck!
Whenever I try to add a file with whitespace in its name to git, it shows an Error as
"fatal: pathspec 'Tic' did not match any files"
Since I was New to git and Linux based terminal I have no idea how to do it.
Screen-shot or my error:
You should be able to quote the filename (eg. "file name"), or use an escape sequence (eg. file\< space >name).
To expand on #ergonaut's correct answer, just for the sake of clarity, this is actually neither a git nor a Linux issue. This is just a general requirement for command lines across the board.
On any command line, each word (or in this case, string of words) is evaluated separately as either a command or a parameter to a command. So, for example, git's add command is expecting a single parameter to come immediately after it (a filename). In this case, the next word it sees is just "Tic". Since it's only looking for a single parameter, it stops evaluating anything else at that point and that's why it's complaining about not being able to find the "Tic" file. When the words are enclosed in quotes, the entire string is evaluated as a single parameter, therefore fixing the issue.
Always wrap filenames that contain spaces with quotes when using them on the command line. Or even better, avoid using spaces in filenames. :-)
Try:
git add Tic\ tac\ toe.c
\ is used to escape special characters, though this is more bash related rather than git specific.
Alternatively, you could put the name of the file in quotes.
git add "Tic tac toe.c"
Start writing the first word and then press "Tab" button to use autocomplete
and you will be happy ))
Let's say, the user drag and drops an file into my batch file, which causes that the batch file copies the file to a certain directory. the problem is the following command:
copy "%1" "C:\path\to\it"
The problem here is the quotes around%1. When you drag and drop something in a batch file, normally, it wouldn't put quotes, so everything's fine. But when i convert my batch file to EXE, it actually puts quotes there.
So, what i want to do is, checking if the file does have quotes, if not, than do the command above, otherwise, do the command without quotes.
Thanks.
Would the following work?
copy %1 "C:\Dir1\Dir2"
my few attempts to find a problem not quoting %1 have not resulted in adverse effects.
Not sure if the answer given here was what you were seeking, and I may be a couple of years late, but I would like to offer an alternate solution to your quoting problem as I have run into it something similar myself. Maybe it will benefit someone else.
You ARE able to strip the quotes from around variables, including the ones that are dragged and dropped. Here's how:
add a tilde to the %n variable (e.g., copy %~1 "C:\path\to\it")
For other variables within the batch file, use a similar technique, this time performing a substitution of the double-quote for nothing :"=, as in:
set filename="C:\path\to\it"
echo %filename% (will give you "C:\path\to\it")
set noquotefilename=%filename:"=%
echo %noquotefilename% (will give you C:\path\to\it without the quotes)
It is not my original solution, but I found it near the bottom of the following post:
Removing double quotes from variables in batch file creates problems with CMD environment
The substitution technique has other applications, as you could easily substitute any character for any other (e.g., :\=_ to substitute a back-slash for an underscore).
Hope this helps!
The problem is the process by which you are converting to EXE. Try a different BAT to EXE converter.