The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
If a person is using = in their file names then they don't deserve for their solution to work correctly anyway.
You talk like a Linux guy!
I was just ordered to remove case insensitive file name matching in this Windows specific tool that I will be maintaing: The routine looked for CMakeLists.txt, and I was told that anyone who uses a different casing for this file is simply doing it wrong - even though the file system explicitly is case insensitive. Case insensitive matching is "unnecessary" in this case, get rid of it!
Up until five to ten years ago, there was a heavy demand from the Linux community that file names should never contain space. We still have tools ported from Linux that crashes if they encounter a file name contianing space, with no way of quoting it properly from the outside because the tools derive the names of new file from it, without considering any qouting. One tool would even barf if it encountered a file with a space in the name even if that file was not referenced: The tool searched a directory, and crashed when trying to stat every file. So we had to make sure that noone put a (completely unrelated) file with a space in the name in any directory used with this tool.
A number of years ago, even Linux based software was forced to accept 8 bit characters (in ISO 8859 format) without stripping off the "parity bit" - but still there are lots of legacy tools that handle it poorly, and you may have to know all the different ways of quoting to get it right if you are working in a command shell. Today, even Linux (at least some distros!) even accept Unicode file names - but don't expect every application to handle it well!
Lots of businesses and organizations have names including a slash: A shareholder's company is in Norwegian an "aksjeselskap", an "A/S". Ships are often named by the kind of ship: "M/S Norway" is the SailingShip Norway, and so on. Such use of slashes in abbreviations are common in many European languages. Lots of Linux software will have problems if you use these organization names in file names. It used to be OK in DOS/Windows, but the pressure was too strong to accept ported *nix applications without adapting them at this point, so just to be kind to those *nix guys, DOS/Windows (sorry... DOS_Windows ...) introduced problems for the user by accepting the slash as an alternative path separator.
It has been claimed that the backslash was deliberately selected as the directory separator in DOS, rather than the forward slash, to avoid conflicts with traditional use of slash in names.
We may see that as a give-and-take: End user communities sacrified the slash in exchange for beyond-7bit-ASCII file names. Without the pressure from the Windows side, I am sure that Linux file names would have been at ASCII level even today.
If you manage to create a file name containing a wildcard (to non-computer people, calling a file "What to do now?" or "*** IMPORTANT POINTS ***" would be perfecly natural), you will run into problems.
In a CLI environment, names including a "&" (like in "Jonhs_Fish&Chips") may require quoting if used on the command line. Nor are ">" and "<" great as file name characters, as well as a number of other characters, e.g. used to identify alternate streams, or in some older file systems (non-Windows/*nix) file version.
Lots (but not all) of these restrictions are due to command line interfaces - the applications could have handled it, many don't but assume that e.g. a space terminates a file name (especially *nix born software).
But equal signs are still legal. You argue for restricting the set of "legal" file names even beyond that which is imposed by the file system itself. I think this is the wrong way to go. Ordinary people do not recognize the technical grounds for probiting any of these characters, and being told that that "they don't deserve for their solution to work correctly" because they use file names that make perfectly sense to them - and in this case even is a "technically" valid file name - is not the way I want software to move. It should rather go in the very opposite direction!
Ordinary people do not recognize the technical grounds for probiting any of these characters
Ordinary people won't be creating solutions in Visual Studio in the first place.
The point isn't that people shouldn't be able to use =, the point is that there shouldn't be a need to name a file with an = symbol in it. Can you provide a reasonable example of a filename that you would add to a Visual Studio project that contains = symbol?
That's a fairly standard format for property files, and has been since the early days of Windows. Unfortunately when they moved to the modern file systems and allowed (more or less) any character in a filename, there were unforeseen consequences.
Yes but that "standard" was created long before the days of XML, and used by other manufacturers. And, to be fair to Microsoft, they have used XML in many other places, including Visual Studio project files.
I see the basic problem as caused by a "command line philosopy". There is a strong correlation between textual command line input and textual configuration files as input to a program system.
Configuration (and similar) info should be stored in some "binary" format. If you don't want to use a fullblown database, at least the configuration file should be built from Tag-Length-Value records, with an unrestricted Value field.
If, say, MS had promoted a basic TLV structure common to all system needing configuration info, a general reader/editor for this forma could be written, by MS or by anyone else. Such an editor could of course provide various export formats for use in Linux and other legacy systems, adding quoting as required by that format. But the authoritative file should be in the TLV format with no values - file names or others - being restricted by configuration file formats.
I'm just curious because I feel like I'm in the minority where I really don't care for using extensions where a CIL tool will do. I find them more flexible. They don't require an "installation" into visual studio. You don't have to worry that they won't work from inside a build script.
Like for example, I was just thinking about creating a tool that will package your current solution for distribution on the codeproject.
My two options are to:
1. write it as a VSIX visual studio extension/add in that will provide a button or menu option to package the solution for code project. It would work using the Project/ProjectItem stuff in EnvDTE. You use it (in theory) by right clicking on the solution and clicking "package for codeproject"
2. write it as a command like tool that simply parses the project files out of the csproj xml files and by reading the directory tree. You use it by making it a post build step on one of your solution projects.
I lean toward the latter. I think a lot of people would prefer to use the former. What do you prefer?
One issue I've found with VSIX, and YMMV because it really depends on how you use it, but let's say you have some sourcecode that is generated by a tool as part of your build process.
With a CLI you can copy the tool into your source directories somewhere, and reference that. That way anyone who copies your sourcetree can rebuild the project (including the the custom build steps that invoke your tool)
With a VSIX extension that doesn't work. First, they're huge, so copying it to a sourcetree folder is not necessarily feasible. Second, and perhaps more importantly, they need to be installed. The upshot of that is another developer cannot build your sourcecode without running an installer first.
That's why I'm heavily in favor of a CLI for build tasks in visual studio. For other VS productivity tools, that may not be my preference.
I have about 15 different tools as part of my building process - including code generators (called Custom Tools in VS), all implemented as VSIX package...
With that said - it is not code to share and those extensions are only part of the build in the development process and not there for the final build, so I'm on the easy side...
And yes - I had a case when I had to create a CLI version of the VSIX package to participate in command line build (part of DevOps agent)...
honey the codewitch wrote:
they need to be installed
This is the only problem with them...
So obviously - and as always - it depends...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
I consider command line tools to be a close relative of assembly programming.
Some people really take pleasure of demonstrating that they know by heart every single command line option / flag for two dozen different command line tools (the description of all the options for gcc comes in three hardcover volumes...).
Sorry, that is not for me. I more and more get a feeling that "fully mastering advanced tools" takes a strong precedence over "mastering the design of a good problem solution for the customer", especially among young programmers. Command line affectionados should by law be forbidden to develop end user applications.
Doesn't really matter - the developers are the users of the tools.
And a thousand CLI apps with easily forgotten switches is one of the reasons why people abandoned DOS and switched to Windows - including developers! Remember the old days and creating batch files to compile you project(s) because the switches were so "memorable"? I do ...
I only create CLI apps now that don't need any inputs even as a one off because it's easier to create, test, debug, and use a GUI app than remember what to type!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
You make very good points. I've always felt however, that a build should be able to be accomplished from a command line script, for testing, source control/build control, and sometimes even deployment reasons.
I do prefer to be able to actually *do* everything from a GUI, but I do use CLI prebuild and postbuild steps, which only need to be typed into a project once, are saved with the project (persistent), and after that they are automatic any time the project or containing solution is built.
They also are easier to distribute along with the source for the project itself, because they don't require an install. Basically, if I enter pre/post build steps into the relevant projects, and those get performed by exes that are in the solution folder somewhere then all someone has to do is copy my source tree to be able to build it. Using the VSIX option means they
A) Need vstudio to build
B) more importantly perhaps, they need to run an install! before they can build
I really don't like that. Consequently, in this case I prefer CLI methods.
Real programmers use butterflies
Last Visit: 8-Jul-20 2:31 Last Update: 8-Jul-20 2:31