I have this in my .install4j file:
<mediaSets>
<windows ...
mediaFileName="${compiler:product.name} ${compiler:edition.name} Win32 ${compiler:sys.version}" ...>
<mediaSets>
The issue is with the name of the generated media file.
I get: Our-Product_Enterprise_Win32_6.0.36-SNAPSHOT.exe
I want: Our-Product Enterprise Win32 6.0.36-SNAPSHOT.exe
I switched off the "Convert dots to underscores" setting, which helped clean up the version number, but how do I prevent Install4J from replacing all blanks with underscores?
I could live with using some other character, but:
_ (underscore) is confusing since the name already has dashes in it (it should be possible to read out a name over the telephone).
- (dash) is even more confusing since there are more dashes in it.
~ (tilde) looks weird - the installer is seen by non-tech people, and I don't want to confuse them.
en-space and em-space might work, but could cause character set weirdness, particularly since we're building Linux and Windows installers (and maybe Mac installers in the future). I.e. I'll want to stick with ASCII-7 if at all possible.
Currently this is not possible. For 8.0.3, I have now implemented an option "Convert spaces to underscores" so you can disable the replacement.
Please contact support#ej-technologies.com to get a build where this is already implemented.
Related
how do you open a file of which name contains UTF-8 character?
For example:
(open "~/a/你好.txt")
give this:
The filesystem does not accept filenames with extended characters: "~/a/你好.txt"
I'm using ecl 16.1.3 from emerge from gentoo.
Meantime, sbcl can open the file.
I'm pretty sure ECL simply does not support general unicode filenames on Unix or Linux, however they get encoded in the underlying filesystem (I also don't know how that happens with *nix nowadays, although I guess there must be a standard now).
The specific error you're seeing originates here, in pathname.d. If you then look in unixfsys.d you'll see that ECL_NAMESTRING_FORCE_BASE_STRING is one of the flags passed to ecl_namestring all over the place, and this isn't conditionalized by anything.
So at the very least you would need to compile ECL from scratch, and more probably it simply does not support general unicode filenames at all.
I'm interested in the encoding of the character in the computer.
When I open my xxx.c with visual studio code, how does the VS code detect the encoding of my file and interprets these "01" sequence. Further on, how the visual studio code (or even the computer system) display the character on the screen acorrding to my "01" sequence file and the character encoding?
Thank you!
I also uses Chinese during my projects. Sometimes, the file encoding really drive my crazy. Sometimes,my correct utf-8 file created by edit A for example, was destroyed by some text editor B that interpret it as GBK file, and edit A can never get it back correct.
I searched a lot, but the most answers seems to be too abstract or irrelevant. I want to figure out how the software and the computer system( or operating system) cooperate together to make this simple but important job done!
First things first, "can never get it back": Always Use Source Code Control
"How the software and the computer system (or operating system) cooperate together to make this simple but important job done!": They don't that's the problem!
Short history: Many decades ago people used small character sets. The idea was a system would always use the same one. Simple. Every time a text file was transferred between systems, it would be immediately transcribed to the local character encoding. Then came the globalization of file exchanges and systems needed to hold text files in different encodings. There was no general way of recording what the encoding was. In 1991 came the huge character set Unicode. Languages (VB4, Java), operating system APIs (Win32), file systems (NTFS), … began adopting it. However, its encodings (UTF-8, UTF-16) are just yet more possibilities for which encoding a text file uses. Many programs that read text files either rely on the old system of a system default encoding or guess ("detect").
In the programming world, some languages require source files to use a specific encoding (say UTF-8); In others, tools default to specific encoding (say UTF-8). In most cases, the toolset provided with a C or C++ implementation will have a consistent set of rules. If you also use an IDE or other form of project system, you can set the encoding for the entire project and in some cases specific files.
So, the only solution is to only use tools that work for you and to properly configure them. If it hurts, stop doing it.
Aside: On the topic of programming and default character encodings, be careful not to get tricked with various language libraries' use of the system default character encoding—unless that is exactly what's needed. Otherwise, you are giving your users the same problem that you are encountering. (In Java, just avoid it with explicit arguments. In C and C++ libraries, encoding is combined into Locales. But note that many systems initialize a program to use default character encoding.
My problem is when comparing a branch with the trunk (or vice-versa), using the option Compare With → Branch/Tag the Eclipse I'm using (Neon) points many special characters like ç, ã, õ ... as changed, but I really didn't changed anything there. This makes harder to see the real differences.
Is there an option to disable this check?
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...
I am using Eclipse 3.6.1 Build id: M20100909-0800 and Aptana Studio 2.0.5 which is based on Eclipse 3.5.2 (both on OS X) and in both programs the external tools feature seems to swallow double quotes and whitespace for the ${selected_text} variable.
Isn't the ${selected_text} variable essentially useless with the mentioned behaviour?
Is there a way around that or maybe a hidden setting somewhere?
Thanks for reading.
This could easily be considered a safety/security feature.
I suggest "${selected_text}".
...but if it's eating ALL whitespace, that won't really help. Huh. Maybe it's clever enough to detect the quotes and preserve the whitespace... but probably not.
Okay, I did a little poking around. Quotes within the argument list itself are preserved, as per my initial suggestion above. I found the following auto-generated argument list that was working Just Fine:
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-debug "${workspace_loc:/com.cardiff.bpm.ide.webforms.ui/debug.options}"
But if your text selection contains quotes, I'd expect it to be handled as per the underlying OS. Windows "cmd" does some... creative things with them for example. My *nix-fu is Not Mighty, so I couldn't tell you what OS X will do under the covers, but I suspect that's where you'll find your solution.
You may have to do something goofy like URL-encode your selection, and use some command line tool to un-encode it before passing it to your desired external tool once the text is out of Eclipse's clutches.
A (very) quick look around my 3.6.1 UI didn't turn up that would do this automagically for you, but there's probably a plugin out there somewhere that'll add that feature to an editor's context (right click) menu.
I'd expect the HTML editor to have this ability already... but I don't see anything other than "smart insert mode" that sounds promising, and I don't see that working either.
That doth bloweth goats, most heartily, yay for weeks on end. E'en till yon goat hath a rash, most unpleasant in both severity and locality. Verily.
I don't think you're getting my proposed solution:
Set up your tool so it'll de-url-encode-ificate the incoming string with some proposed command line tool.
In your editor (in eclipse), URL-encode the text you wish to select and pass to the tool. Manually.
Run the tool on the selected (url-encoded) text.
Revert the selected text. Also manually. Probably just "undo".
"1" is why I was looking for some eclipse UI way of url-encoding a selection. The HTML Editor won't even do it when you paste into an attribute string. Sheesh.
Two Other Options:
Fix the bug yourself. Open Source and all that.
Write a plugin that exposes it's own version of ${selected_text} that doesn't strip out all the strings.
Hey! SED! Replace the quotes with some random (unused in any selection you might make) high-ascii character and sed it back to a double quote instead of the proposed de-url-encode-ificationizer. You'd still have to manually edit/undo the text, but at least you won't have to """ Actually search/replace over a given selection makes that less painful than one might think.
I'm not sure what the scope of #2 is, but I'd image if you don't have any eclipse plugin experience the thought might be rather daunting. There might even be a sample plugin that exposes such a variable, though I haven't checked.
I don't think we're communicating.
You don't select text with quotes in it. You select mangled text, and sed demangles it back into quotes for you.
For example, you have the string print("hello world"); in your editor and want to send that to your tool.
change it to print(~hello world~); in your editor. Manually or via a script or whatever.
select it
run your tool, maybe wrapped in a script that'll sed the ~s back to "s.
change it back to print("hello world");.
This is a manual process. It's not pretty. Bug workarounds are like that. You can probably come up with a monkey script to convert quotes to Something Else, and "undo" is easy. You might even be able to get your script attached to a keyboard short cut... dunno. And ~ is a lousy choice for a replacement character, it's just the first thing I could think of that was rare enough to be a decent example.
Are we communicating yet?
For the record, I put together a patch using some guidance from a gentleman in the bug comments.
I don't know if it will be accepted, but it fixes things for me so maybe someone else may find it useful.
Again, this is only for Mac OS X Eclipse.
Start Eclipse.
Go to Import > Plug-ins and Fragments.
Import From: Active Platform
Fragments to import: Select from all plug-ins
Import As: Projects from a repository
Next >
Pick org.eclipse.debug.ui and org.eclipse.debug.core
Once the projects are in your workspace, apply the two patches that compose proposed patch v1, found at the bug tracker page for bug 255619
Go to Export > Deployable plug-ins and fragments and make a jar out of your changed packages.
Hope it helps.