Under linux, I do the following
COMMAND /home/directory/*.txt
and all the files in that directory get passed as separate parameters (20 files in the directory results in 20 parameters in the argv variable)
Under windows, the same command results in one parameter (that string exactly).
Is this a compiler issue (VisualC++ 2008) or a windows thing or what?
In the past, I've written batch files to parse the files into multiple parameters, but I'm hoping there's a better way.
Any help would be appreciated
It's somewhat more limited than most Unix shells, but VC++ includes a file named setargv.obj that you can link with to add globbing to your application. It supports * and ?, which covers most of what most people care about.
To use it, just include setargv.obj when you link your file. In most cases, this just means adding the file name to the command line, something like this:
cl myfile.c myotherfile.c setargv.obj
Indeed that is a shell globbing feature. In PowerShell you would handle wildcard expansion inside your function using Convert-Path (or Resolve-Path) e.g.:
function ITakeWildcards([string]$Path) {
$paths = Convert-Path $path
foreach ($aPath in $paths) {
"Processing path $aPath"
}
}
Related
To answer "where did I also use this identifier?" -questions, I run on macOS and the linuxes
dired-maybe-insert-subdir
dired-mark-files-regexp
followed by either of:
dired-do-find-regexp
dired-do-find-regexp-and-replace
On Windows I can get by using Emacs as my IDE without Cygwin, except for dired recursive search/replace.
Does Projectile
offer commands that will search/replace an identifier recursively without requiring Cygwin?
Does any other package make recursive search/replace possible on Windows without Cygwin?
I'm not concerned about the speed, because even after installing Cygwin, the recursive invocation of Cygwin's grep from within Emacs is painfully slow.
Update:
Recursive search/replace seems to be available in both
Helm
and
Projectile.
If true, then my question is:
Is the feature available on Windows without Cygwin?
The list of requires in my .emacs is already excessive. What is a light package that will do recursive search/replace (without Cygwin on Windows)?
Clarification:
OK. Success. [Thanks to Drew] With a .emacs containing nothing but (require 'dired+), I can search-and-replace in marked files using M-+ Q on Windows without having Cygwin installed. I'm guessing that this will also work on linux/macOS, although perhaps not quite as quickly as delegating to grep. (The "Act on ALL files [] in and UNDER this dir?" confirmation message will start to get tedious, but that's a separate question.)
For the present question one issue needs clarification. dired+ augments the built-in dired family of commands. Is there a way for it to take over ordinary dired-do-find-regexp-and-replace? That's because with the one-liner .emacs, and with a few marked files in a directory listing, I get
File not found - GREP
File not found - -I
...
File not found - NUL
File not found - ;
indicating that grep is still being invoked. How can tell dired+ "I'm on Windows and I won't install Cygwin; please take over A and Q?" (mapped by default dired-do-find-regexp and the aforementioned command).
Editorial: dired+ seems a bit overwhelming, but if it solves this one problem (eliminate the need for Cygwin on Windows), it will be well-worth figuring out how to move from the usual dired commands to dired+.
I think you're looking for a way to search files and get a list of those that match a regexp. If tags-query-replace works for you on MS Windows (without Cygwin), and I think it should, then you can use command diredp-do-query-replace-regexp-recursive, bound to M-+ Q by default, available from Dired+.
That acts on all marked files in the current Dired buffer, and on all marked files in all of the buffer's marked subdirs, and so on, recursively.
With a non-negative prefix arg it acts on all files in the current buffer and all files in all subdirs, and so on, recursively. (That is, any marks are ignored, and the effect is as if everything were marked.)
If, instead of finding files that match a regexp, you want to search through files then you can use command diredp-do-isearch-regexp-recursive, bound to M-+ M-s a C-M- by default, also available from Dired+. The files to access are defined similarly (all Dired+ dired[p]-do...-recursive commands act similarly wrt which files are identified to act on). That definitely does not require any Cygwin etc. commands - it's just Isearch.
I face with a problem in linking phase, while working with MSVC9 . It says:
NMAKE : fatal error U1095: expanded command line link.exe . . . too long
You can get nmake to write the command line arguments to a file, then use the link option to read the arguments from the file.
Look for "inline files", eg http://msdn.microsoft.com/en-us/library/z440c98k(v=vs.80).aspx
It's a very long time since I did this, but as I recall the usage is something like:
foo.exe : foo1.obj foo2.obj foo3.obj
link.exe #<<
foo1.obj
foo2.obj foo3.obj
... more arguments, macros etc on one or more lines
<<
rem other commands go here if you want
Essentially you just have an ordinary nmake command line, but the pair of << markers tell nmake to write the options to a file (and they are replaced by the name of that file), and then # tells link to read arguments from that file.
The KEEP option (possibly with a specified file name) can be useful for debugging - if link barfs, you can look in the file to see what you actually passed to it.
There's not much you can do about fixed command line lengths in your tools. You might like to try and combine your object files into a couple of libraries, and then perform the final link and link the libraries together. This will introduce another step into your Makefile, but will get around the command line too long error.
lol that sucks but we need more information to answer your question. OS for starters, basically, it is saying that the command line to call the linker is bigger than the buffer allows in cmd.exe itself. If i remember correctly there may be a way to make the command shell utilize a bigger buffer on the command line. Or you can possibly change the shell to windows powershell and see if that might work.
I have an application built with the MinGW C++ compiler that works something like grep - acommand looks something like this:
myapp -e '.*' *.txt
where the thing that comes after the -e switch is a regex, and the thing after that is file name pattern. It seems that MinGW automatically expands (globs in UNIX terms) the command line so my regex gets mangled. I can turn this behaviour off, I discovered, by setting the global variable _CRT_glob to zero. This will be fine for bash and other sensible shell users, as the shell will expand the file pattern. For MS cmd.exe users however, it looks like I will have to expand the file pattern myself.
So my question - does anyone know of a globbing library (or facility in MinGW) to do partial command line expansion? I'm aware of the _setargv feature of the Windows CRT, but that expands the full command line. Please note I've seen this question, but it really does not address partial expansion.
I've ended up using conditional compilation to write my own globbing code for the Windows version of my app. This was pretty easy as I have my own CommandLine class which encapsulates argc and argv from main(). Still, I'd be interested to hear of other solutions.
<glob.h> has glob and globfree and lots of flags for glob.
I'm not sure if I fully understand your problem here, but in Windows you should be able to glob using FindFirstFile / FindNextFile functions from the WIN32 API. Honestly I don't know if their globing capability is comparable to glob() but you could give them a try
I have a C shell script that calls two
C programs - one after the another
with some file handling before,
in-between and afterwards.
Now, as such I have three different files - one C shell script and 2 .c files.
I need to give this script to other users. The problem is that I have to distribute three files - which the users must keep in the same folder and then execute the script.
Is there some better way to do this?
[I know I can make one C code file out of those two... but I will still be left with a shell script and a C code. Actually, the two C codes do entirely different things... so I want them to be separate]
Sounds like you're worried that your users aren't savy enough to figure out how to resolve issues like command not found errors and the like. If absolutely MUST hide "complexity" of a collection of files you could have your script create the other files. In most other circumstances I would suggest that this approach is only going to increase your support workload since semi-experienced users are less likely to know how to troubleshoot the process.
If you choose to rely on the presence of a compiler on the system that you are running on you can store the C code as a collection of cat $STRING >> file.c commands to to create your two C files, which you then compile and use.
If you would want to use pre-compiled programsn instead then the same basic process can be used except instead use xxd to both generate the strings in your script and reverse the conversion process to give you working binaries. Note: Remember to chmod the binary so that it is executable.
use shar command to create self-extracting archive.
or better yet use unzipsfx with AUTORUN option.
This provides users with ONE file, and only ONE command to execute (as opposed to one for untarring and one for execution).
NOTE: The unzip command to run should use "-n" option, that way only the first run would extract the files and the subsequent would skip the extraction.
Use a zip or tar file? And you do realize that .c files aren't executable, you need to compile & link them first?
You can include the c code inside the shell script as a here document:
#!/bin/bash
cat > code.c << EOF
line #1
line #2
...
EOF
# compile
# execute
If you want to get fancy, you can test for the existence of the executable and skip compiling them if they exists.
If you are doing much shell programming, the rest of the Advanced Bash-Scripting Guide is worth looking at as well.
I'm trying to use 7-Zip to zip up a file via the system() function in C++ on a windows XP machine.
I tried:
(formatted to be what system() would have received)
"C:\Program Files\7-Zip\7z.exe" a -tzip "bleh.zip" "addedFile.txt"
which spat the error
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
I've tried several similar alternatives but have not yet found a solution.
I want to try to run it straight from its install directory so that as long as a user has 7-Zip installed it will be able to function. This is for an in house utility application.
EDIT:
as requested these are the actual lines of code:
std::string systemString = "\"C:\\Program Files\\7-Zip\\7z.exe\" a -tzip \"" + outDir + projectName + ".zip" + "\" \"";
//...
std::string finalSystemString = systemString + *i + "\"";
system( finalSystemString.c_str() );
*i is an iterator to a particular file that is getting added.
it looks like something is stripping the quotes around the first argument. You could play around with extra quotes to try and fix this, or you can get the MS-DOS compatible short path name for 7z.exe with the Win32 API GetShortPathName
The short path will not have spaces in it, it will be something like "C:\PROGRA~1\7-ZIP\7Z.EXE"
Have you tried escaping the spaces, i.e. "C:\Program\ Files\7-Zip\7z.exe"? That might work, although I don't know the specifics of system().
Another approach would be to use the CreateProcess function in the Windows API. It can deal with spaces in "C:\Program Files" according to its documentation.