I built an application to compile and run java files and it was running completely ok.
Since it is the user to choose the path of java files to be compiled and executed, i quote the path, so that it can contains white spaces and special characters. Like this:
javac "C:\test project\*.java"
Now, i tried out in another computer and now i am having this error:
javac: file not found: C:\test project\*.java
Usage: javac <options> <source files>
use -help for a list of possible options
If i remove quotes and there is no spaces or special characters in path it works, but for the example above, that contains a white space, i get this error:
javac: invalid flag: C:\test
Usage: javac <options> <source files>
use -help for a list of possible options
I've read some threads about this, but i couldn't figured out the solution. Anybody has a clue?
Thank you!
Try quoting only the path and add the *.java after the quote. For example:
javac "C:\test project"\*.java
I've had a script in my test env with the same pattern, which stopped working today. After some research I've seen that the only change is that I've updated from JDK7 update 7 to update 17, and when I go back to update 7 it's working again. Seems that there's a new bug which was introduced somewhere in between. After some trial and error I came up with this workaround, which works for both the old and new javac.
Hope that helps.
* is meaningful to the shell, not to the compiler. When you put the * in the quotes, you are passing it to the compiler, not allowing the shell to expand it. you need to quote the spaces without quoting the star.
However, you'd be far better off using a proper build tool such as ant or maven.
Related
Instead of always giving the --indent n flag on the command line, I would like to specify this in a config file (or library or module file – I'm not sure what the correct terminology is).
I tried putting various things in ~/.jq, such as indent: 4 or --indent 4, but they always gave me a compile error when I invoked jq. I looked at the manual but couldn't see any information on how to do this, nor find anything in the issues on GitHub.
Is it possible?
The ~/.jq file contains jq code such as function definitions. It's not a config file in the classical sense.
Most shells support aliases and you could set one yourself, e.g. in ~/.profile or ~/.bashrc/~/.bash_aliases with:
alias jq='jq --indent 4'
When invoked in an interactive shell, the alias will be resolved to the command including the option. Note however that aliases are ignored in shell scripts (i.e. non-interactive mode) by default.
my scenario is: I'm using vim to open some .cpp files, for example
vim 1.cpp src/2.cpp root/src/3.cpp
Sometimes, I wish to rebuild 3.cpp so I have to use another window to
"rm root/src/3.o"
and inside vim, type
":make"
This works fine, NP. But I am looking for a .vimrc function/command that:
When I switch to buffer, e.g. "root/src/3.cpp" and press this command, vim will detect the directory of "root/src" and the file name without suffix "3", and automatically execute a command of "rm root/src/3.o".
In this case, I can casually switch to any buffer and re-trigger the build of this very file.
Note I don't wish to map gmake tool command like "make clean" because we use several different make utilities like scons, cmake, etc.
So how to write this function/command in .vimrc? Thanks.
:call system('rm '.expand('%:p:r')) as #Kent said, or even simply :!rm %:p:r.
But I'm quite surprised you need to do that. Tools in charge of compilation chains usually understand dependencies (which ever the tool is), and you shouldn't need to remove the object file that often to need a mapping to do it for you.
PS: it's perfectly possible (but I need to update the doc) to support CMake, or out-of-source compilation from vim. But indeed, with out-of-sources compilation, you wouldn't need to delete those files manually, a :make clean if :make already works.
you can get root/src/3 from root/src/3.cpp buffer by:
expand('%:p:r')
Then you are free to concatenate the .o to end, and build the command.
In Eclipse there is an option to specify pre processing defines (#ifdef macros) to a project by using the Symbols option in Paths and Symbols. This helps in effective indexing of code which is cross platform. Is there any option to provide these in Qt creator?
It depends:-)
The following is assuming you are using qmake based projects:
First you can add DEFINES += SOME_DEFINE=value into your .pro file. That is picked up inside creator and when building on the command line and should also show up when creating a MSVC or XCode project from the .pro file.
Then you can add DEFINES += SOME_DEFINE=value to the qmake call that Qt Creator will issue when configuring the project. That happens in the Project Mode, Build Settings, QMake Steps.
Finally, you can put #define SOME_DEFINE value liens into a header file and include that. That works for all kinds of projects:-)
From the QT Documentation:
The defines are specified in the .config file. The .config file is a
regular C++ file, prepended to all your source files when they are
parsed. Only use the .config file to add lines as in the example
below:
#define NAME value
That is, if you import a project named MyProject, then the pre-processor definitions should be specified in MyProject.config
For my projects it causes the indexer to recognize this define project wide and changed the auto-complete to reflect this.
I think the initial answers are good, but they require that you manage your configuration manually whereas there're ways to let the IDE manage this for you automatically based on whether you have a release or debug configuration selected.
This bit may be redundant, but please note that this will work for you only if you are using the IDE for building. Obviously, if this is not the case, you will need a different solution.
Steps
Since pictures are worth a thousand words, here's an example of how you define a debug macro for your debug build using Qt Creator 4.3.1:
Make sure you have your Debug configuration selected;
Go to the Projects section on the left menu;
Go to the Build section
Under Build Steps, look for the Additional arguments input box;
Enter your macro definitions (e.g. DEBUG for your #ifdef DEBUGs in the code; in my case it's __CTS_DEBUG__)
The macro will now only be defined when you're using your debug config; when you choose your Release config (see step 1), it will become undefined automatically and your conditionally-compiled debug code will be removed, as shown in the pictures below, which is just what you always wanted.
Results
With the debug config selected
With the release config selected:
I wanted to specify a #define string in the .pro file, but my code ended up with the contents of the string without the quotes. I had to escape the quotes, and then escape the escapes to get one pair of quotes to last all the way to my code. This is because qmake strips off one set of escapes and some quotes, then the command line strips off the rest of them. This worked for me:
DEFINES += "VERSION=\"\\\"0.1.0\\\"\""
On Windows, this VERSION string can then be used in the .rc file to create the version stuff where Windows wants it and as well as in code for an "About" menu.
You can define some PREPROCESSOR in the Project settings in QtCreator. I do not have QtCreator here but i remember there is a tab for project configuration.
First suggestion from #Tobias Hunger's answer worked for me. I was doing this in my .pro file:
DEFINE += KEY=value
which did not work until I changed it to:
DEFINES += KEY=value
That said, if you want to do everything from the command line, an almost hybrid solution that does not use Qt Creator GUI, but does use .pro files, is described here:
https://www.linux.org/threads/c-tutorial-create-qt-applications-without-qtcreator.18409/
Using the method described in the above link, you can use qtcreator -project to produce a .pro file, then use notepad or vim or some other text editor to add the DEFINES += KEY=value line to the .pro file you just created. Then use qmake thusly: qmake <your_project>.pro, to do the Qt pre-processing, and finally just make to build an executable.
I've also heard lore of a qtcreator -D option to add preprocessor defines from the command line as described here:
https://doc.qt.io/archives/qt-4.8/qmake-variable-reference.html#defines
but I've never tried it.
Hope something works for you! Your dedication to the CLI is admirable.
I am trying to convert a PDF document into a PNG file using ImageMagick command line tools from a ASP.NET website. I create a new shell process and ahve it execute the following command:
convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
This runs well when testing the website on my local machine with the ASP.NET Develeopment Server of VS and the command also works well when manually entered into the shell. When running from the programatically created shell in ASP.NET there is the following error message:
Invalid Parameter - 96x96
Does anybody know why that happens and what to do?
I have tested the command while being logged in on the server via RDP with a different user account than the ASP.NET process. I have used exactly the same ImageMagick and Ghostscript installation files as on my local machine and have activated adding the ImageMagick installation path to the enironment variables during installing. The server has not been rebooted since than.
convert is also the name of a windows executable which converts FAT filesystem to NTFS. When you do not specify the full path of an executable, quote:
...the system first searches the current working directory and then
searches the path environment variable, examining each
directory from left to right, looking for an executable filename that
matches the command name given.
"C:\Windows\System32" is generally present in the beginning of %PATH% variable, causing the Windows convert utility to launch, which fails with "Invalid Parameter" error as expected.
Try specifying the full path of the ImageMagick's convert.exe like so:
"C:\Program Files\ImageMagick\convert.exe" -density 96x96 "path_and_filename.pdf" "path_and_filename.png"
As others have stated convert points to a different program in your PATH. Instead preface your command with magick. So your command would instead be:
magick convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
In Window actually exists a "convert.exe" in system32 - make sure your script doesn't start that one (maybe the environment paths on your development machine are set differently).
I am only answering this late because imagemagick was updated. Now, if you wish to use the "convert" command, you do it like this:
magick convert "image.png" "document.pdf"
or
magick convert "image_00*.png" "document.pdf"
for multiple images.
Same syntax for command, just add magick before it
A couple more options for fixing this:
Edit your Path system variable to contain the path to imagemagick
as it's first content and then add the rest after it. This will make
windows always find the imagemagic convert first before it finds
the other convert program. So something like this: C:\Program Files\ImageMagick-6.9.2-Q16;C:\Program Files\Haskell Platform\2014.2.0.0\lib\extralibs\bin;...
Another option is to create a dedicated folder somewhere on your machine where you will place shortcuts for some of these name clashes. Then what you do is that you rename those shortcuts to meaningful names, for example convert_image_magick, then add the path to this folder to your system path. So now as you hit tab more, you will finally find the right program you want to run
yes! if you launch an Administrator command window it defaults to C:\windows\sytem32\ ... as long as you're not in that directory the command will pickup the ImageMagick convert.exe
My issue was I was using the "FORFILES" command which is tricky because it requires using
"cmd /c" and passing the convert command with #path and #file parameters and it does some escaping of slashes... needless to say it's caused me hours and hours of headache. It even parses hex characters, like if your filepath has the combination 0x00 in it, it will think that's a hex value and mangle your path. I had a filepath named C:\ImageRes3000x3000
and FORFILES interprets that literally and it caused a strange path issue. Sorry if this is a long useless post but it's meant to be FYI, if someone runs across this, maybe it will help them. That being said, FORFILES and "convert.exe" are a powerful and simple image renaming line script combo.
here's my full 3 line image renaming script
robocopy D:\SRC_DIR\ D:\DEST_DIR\_staging *.jpg /e /MAXAGE:2
FORFILES /P D:\DEST_DIR\_staging\ /S /M *.jpg /C "cmd /c convert.exe #path -quality 65 -resize 1500 D:\RESIZED_DIR\\#file"
DEL D:\DEST_DIR\_staging\*.* /S /Q
At a unix command line, what's the difference between executing a program by simply typing it's name, vs. executing a program by typing a . (dot) followed by the program name? e.g.:
runme
vs.
. runme
. name sources the file called name into the current shell. So if a file contains this
A=hello
Then if you sources that, afterwards you can refer to a variable called A which will contain hello. But if you execute the file (given proper execution rights and #!/interpreterline), then such things won't work, since the variable and other things that script sets will only affects its subshell it is run in.
Sourcing a binary file will not make any sense: Shell wouldn't know how to interpret the binary stuff (remember it inserts the things appearing in that file into the current shell - much like the good old #include <file> mechanism in C). Example:
head -c 10 /dev/urandom > foo.sh; . foo.sh # don't do this at home!
bash: �ǻD$�/�: file or directory not found
Executing a binary file, however, does make a lot of sense, of course. So normally you want to just name the file you want to execute, and in special cases, like the A=hello case above, you want to source a file.
Using "source" or "." causes the commands to run in the current process. Running the script as an executable gives it its own process.
This matters most if you are trying to set environment variable in current shell (which you can't do in a separate process) or want to abort the script without aborting your shell (which you can only do in a separate process).
The first executes the command. The second is shorthand for including a shell script inside another.
This syntax is used to "load" and parse a script. It's most useful when you have a script that has common functionality to a bunch of other scripts, and you can just "dot include" it. See http://tldp.org/LDP/abs/html/internal.html for details (scroll down to the "dot" command).
Running "runme" will create a new process which will go on its merry little way and not affect your shell.
Running ". runme" will allow the script "runme" to change your environment variables, change directories, and all sorts of other things that you might want it to do for you. It can only do this because it's being interpreted by the shell process that's already running for you. As a consequence, if you're running bash as your login shell, you can only use the "." notation with a bash script, not (for example) a binary on C shell script.