In Windows, command line options are preceded by /, sometimes by -. Is there a way to query Windows for this character? In MS-DOS, there was a SWITCHAR setting in config.sys. Is there a similar setting or system resource which can be obtained from Windows? Or should my command-line app simply use / or - without looking anywhere?
I don't think there was ever a way that this was exposed externally. Perhaps some DOS 2.0 commands checked it, but nothing else did.
"SWITCHAR was never really supported, even by DOS commands (let alone third-party programs)." [source]
I assume third-party programs were expected to parse config.sys themselves. I don't think there was any Windows support to get this particular value. (A Larry Osterman blog post talks about the history of SWITCHAR and hints that there might have been OS support for it once upon a time.)
Best practice is to allow either.
Related
Win32::Console::ANSI enables by default a ANSI(Win) to OEM(Dos) mapping. When I use Win32::Console::ANSI in a CPAN module should I keep this mapping or should I disable this mapping with \e(U?
The documentation outlines the reason this is the default:
It is useful because one types the script with a Windows-based editor
(using a Windows codepage) and the script prints its messages on the
console using another codepage: without translation, the characters
with a code greatest than 127 are different and the printed messages
may be not readable.
That seems to be a sensible default for an ANSI console emulation, as it aims to avoid unreadable messages. If, when people are using your CPAN module, they can reasonably expect an ANSI console, maybe it's wise to leave the defaults as they are. What you might want to do is allow people to choose the behaviour as an option when they load/configure your module. But in any case, make it really clear in the documentation what you're doing and why.
I've got a makefile (a file called 'Makefile' which is run by cmake in Linux, but works in Windows via nmake I believe and needs to be run in VS command prompt.)
And most of the 'sample' ones I can see are just one line (and the rest appear to be stuff I don't 'yet' understand and then this same one line.
include $(shell rospack find mk)/cmake.mk
(in the terminal rospack find [package] returns the path to said package, and cmake.mk is obviously the file it wants to include)
My problem is, that this appears (to me at least) to be written for use in a Linux system (which basically the entirety of ros, the program I'm working with, was) and in Windows this appears to just try to be
include /cmake.mk
(which unsurprisingly doesn't work)
Basically I need to know how to do the same thing in windows, generally in a 'dynamic' way, as it will only cause more problems down the line if I get this working by hard-coding the directory path and then it breaks because its not set properly some time in the future)
So I guess if this isn't possible or is particularly hard, a way of hard coding it would be a stopgap.
I tried:
include C:\[directory]\cmake.mk
but it seems to have issues with the ':'
I'm trying to work with Windows, because later in my project I'll be needing to use another program (for i90 robot) for which we only have Windows support.
OK, so apparently it acts differently if the file is actually in the folder.
as in
include C:\[directory]\cmake.mk
Errors with
C:\[directory]\cmake.mk not found
if the file isn't there, and
fatal error U1034: syntax error : separator missing
if it is
While this doesn't really seem to impact on the original problem, I guess it indicates I'm trying to do something funky windows doesn't like.
The short answer is, you'll never get a single makefile that does much of anything complicated that will work both with standard UNIX-style make (such as GNU make from GNU/Linux) and also work with nmake. Nmake is a completely different beast.
As an aside, it's confusing that your makefiles here are called "cmake", because cmake is an actual program, distinct from make (and nmake). I'm assuming, though, from the context that the use of the term "cmake" here doesn't refer to the actual cmake utility. Which is too bad, because if it did use cmake things would be simpler for you. Maybe.
It's not clear exactly what your requirement to use nmake is, though. If you laid out your real requirements, it would be a lot easier for us to advise you. For example, you say you need to use a "another program" which runs only on Windows. What does this program do, exactly, and how will you need to use it? Does it provide libraries that need to be linked with the "ros" code?
Basically, your simplest way forward is to obtain a UNIX-like environment, including tools like GNU make, for your Windows system. There are two main choices: Cygwin, which provides a completely POSIX infrastructure including shell, compiler, etc. which are ports of the GNU environment to Windows but require a POSIX layer, and MinGW, which has various GNU tools that run more or less natively on Windows.
However, if you MUST use Visual Studio as your compiler, for example, then these will be much more difficult to integrate.
How can I go about finding out command line arguments for a given application? I know you can use /? and, if the app supports it, it'll display the switches, but is there a way to find 'unofficial' ones in a program?
Obviously google is the easiest answer... barring that... I don't think there is any special alternative to /? that will give you additional options. You might try running "strings" against the executable in question. That may spit out some hidden options. "strings" comes with most(all?) unix distributions, for windows: http://technet.microsoft.com/en-us/sysinternals/bb897439
If your not familiar with strings... it just spits out every string it can find inside an executable... it's often useful for finding hidden things.
For finding silent install switches, I found Universal Silent Switch Finder 1.5.0.0 to be helpful. Because the original version is very old, I cannot find it on the original website, but softpedia has a download up: http://www.softpedia.com/progDownload/Universal-Silent-Switch-Finder-Download-180984.html
As far as I know, Unix-like systems use UTF-8 for encoding filenames, while Windows system use their own Windows single-byte encodings.
I am working with archives with japanese filenames in them quite oftenly. When I open such archive created in Windows, japanese letters are dead, because filename encoding is incorrect.
Same thing happens, when I create archive in my Linux and then someone opens it under Windows.
So, I have thought that this should be quite common problem, and, because filenames are recoverable there must already exist correcting .sh script for linux and .bat script for Windows.
But after googling for quite a long time I still have not found anything.
Is there such scripts at all? If not, what difficultuies may have stopped people from creating them?
Update
I would be happy with a solution that works for most Linux systems and most Windows systems.
Windows uses the two byte encoding UTF-16. Your problem is most likely that you are using single byte ANSI versions of whatever archive tool you are using.
Until you give more details of the code and tools you are using it's hard to give specific advice. However, the are no limitations on using the full range of Unicode characters in modern Windows file systems.
Thank you for your input. Case indeed looks quite complex for simple bash script, I'll need to use programming language.
I don't see anything like "close question" button, so I'll use this answer to do so.
Take a look to convmv tool available for Unix systems
I work in a pseudo-IT team that does development outside of a formal IT development environment - using Windows XP (and IE6). I can't install any software myself, so can only use what the central IT department makes available - which isn't much.
I have lots of UNIX development experience, so it's painful working without some of the tools I have previously taken for granted.
Notepad is my favorite thing about Windows. What else is there hiding in C:\Windows that I should know about?
Not a great deal, if you're used to the plethora that comes with UNIX. The cmd.exe language has come a long way since the brain-dead version with MS-DOS. It's still no match for bash but it's not bad. Check out Rob Van der Woude's site ("Batch Files" link on the left side) for some fantastic little snippets.
I do know that findstr now does regular expressions so it's at least coming close to grep.
See also this question (which has a couple of answers from me and absolute bucketloads from everyone else) re Windows batch files.
A JavaScript interpreter: cscript / wscript (can also interpret VBScript plus any other language for which a Windows ScriptingHost compliant interpreter is installed)
WordPad: practically useless except for one thing: it can read Unix line endings, unlike NotePad
if you're lucky: PowerShell
Note that plenty of applications are also packaged as so-called portable applications which need no installation: Firefox, NotePad++, even a complete Ubuntu distribution.
ntsd (the Windows NT debugger for user-mode programs - command line stuff, a bit like gdb) was available by default on Windows installations in the system32 directory, although I think that this policy has changed since I can't find it in my Windows 7 64 bit installation.
mmm... not much indeed, besides I think everything that comes out of the box have already been mentioned...
not really answering your question, but I would recommend to use portable software, there's a huge collection of them available, like notepad++, winmerge, grepwin...