I have following definition: !define /date NOW "%Y-%b-%d_%H-%M-%S"
When creating the outfile as such: OutFile "..\my_app_name_Setup-x64_${NOW}_Build_${__COUNTER__}.exe"
compiles successful. However when i change the format to: !define /date NOW "%Y-%b-%d_%H:%M:%S" (Effectively changing the hyphens by colons for Hours, Minutes and Seconds) it no longer compiles successful. (Compile error ´Can´t open Outfile at the very end).
Two (2) questions:
What causes this error?
How can i use my preferred strftime Format? (= with colons for HH:MM:SS)
Maybe Anders can shine a light on this ;)
Add2. as per https://nsis.sourceforge.io/mediawiki/index.php?title=Reference/!define&oldid=24774 tmy formatting ("%Y-%b-%d_%H:%M:%S" is correct. (Might be depreciated(?)
Colons are not legal in filenames on Windows. See Naming Conventions: reserved characters.
If you are compiling on POSIX it is theoretically legal but rather pointless since you cannot execute the installer without renaming it.
Related
In a pre-build event, a batch file is executed to combine multiple SQL files into a single one.
It is done using this command :
COPY %#ProjectDir%\Migrations\*.sql %#ProjectDir%ContinuousDeployment\AllFilesMergedTogether.sql
Everything appear to work fine but somehow the result give an incorrect syntaxe error.
After two hours of investigation, it turn out the issue is caused by an invisible character that remain invisible even with notepad++.
Using an online website, the character has been spotted and is U+FEFF has shown in following image.
Here are the two input scripts.
PRINT 'Script1'
PRINT 'Script2'
Here is the output given by the copy command.
PRINT 'Script1'
PRINT 'Script2'
Additional info :
Batch file is encoded with UTF-8
Input files are encoded with UTF-8-BOM
Output file is encoded with UTF-8-BOM.
I'm not sure it is possible to change the encoding output of command copy.
I've tried and failed.
What should be done to eradicate this extremely frustrating parasitic character?
It has turned out that changing encoding of input files to ANSI does fix the issue.
No more pesky character(s).
Also, doing so does change the encoding of the result file to UTF-8 instead of UTF-8-BOM which is great I believe.
Encoding can be changed using Notepad++ as show in following picture.
How to write strings (&str and String) containing newlines to text files?
In C you can switch between writing text as is or converting '\n' to proper end of line symbol for the OS via fopen flags, "w" or "wb". For example in Windows '\n' is converted to "\r\n" during I/O.
How can I achieve this with Rust? I cannot find corresponding API in std::fs::File.
There is no such API in the standard library (there might be a crate for this, though). The simplest way to write lines to a file is with the writeln! macro and it only uses \n for newlines.
It was probably considered (by the Rust developers) not useful enough because I'm pretty sure that nowadays \r\n is used only for Microsoft Notepad compatibility.
There once was an issue related to write not using CRLF on Windows, but it was concluded that:
the raw io::File will likely not handle it by default but would instead require a wrapper
(note: since Rust 1.0 it is no longer io::File, but fs::File)
I am using awkc to generate an executable file from an awk script. I have the following line in an awk script abc.awk:
BEGIN{printf "Value=%s\n",(3.13+3.26)}
I have generated an executable file (abc.exe), which I have executed on different systems. It gives different outputs in floating point operations.
On one local system it gives the output 6.39 but it gives the output 6 on another system located in a different time zone.
When I searched in various sites I am able to see to set the LANG environmental variable, but how?
I'm not sure that this to do with the locale settings on your different systems but if you are looking for a floating-point number, you should use the "%f" format specifier. To get an answer to 2 decimal places, use "%.2f":
BEGIN{printf "Value=%.2f\n",(3.13+3.26)}
This should give the same result, regardless of the system it is run on.
Edit: based on the linked question, perhaps you should try using LC_NUMERIC=C to explicitly set the locale:
LC_NUMERIC=C awk 'BEGIN{printf "Value=%.2f\n",(3.13+3.26)}'
should work regardless of the system it is being run on.
Environment variables are typically something that you do not control if you hand a program over to someone else. I would look into being more specific in your printf-calls. You can format the numbers into strings in to an astonishing detail. You are probably looking for the float (%f) (you are now using a string (%s).
If you notice that you are making always the same trick with your printf-calls, you can control the number-to-string conversion settings with a variable CONVFMT in a BEGIN-block. I got introduced to this one through gawk, apparently it is however in the POSIX standard. Whether awkc supports this, I don't know.
From the gawk manual:
This string controls conversion of numbers to strings (see
Conversion). It works by being passed, in effect, as the first
argument to the sprintf() function (see String Functions). Its default
value is "%.6g". CONVFMT was introduced by the POSIX standard.
I'm writing this program that's supposed to read from a file, do some stuff with the content and write to an output file preserving the original line endings. If the file has CRLF endings, the output file should also have that. My problem is in writing the line ending especially with the CLISP implementation(it works with gcl). When I try to write a linefeed character(LF), the file ends up having CRLF endings. I'm guessing this is something to do with CLISP's implementation.
I need a way to write the file in binary mode like in other langauages. The standard I/O functions in the specification only take an optional stream name and the content to be written.
You can reproduce that behaviour with something like this:
(with-open-file (out-file "test.dat" :direction :output)
(setf ending #\linefeed)
(princ "First Line" out-file)
(write-char ending out-file)
(princ "Second Line" out-file)
(write-char ending out-file)
(princ "Second Line" out-file))
I need a solution that works in windows.
You need to specify :EXTERNAL-FORMAT argument, mentioning the line terminator mode:
(with-open-file (out-file "test.dat" :direction :output :external-format :unix)
...)
The external format defaults to :dos on windows because that is the standard on Microsoft systems.
Note that you do not want binary mode if you are actually writing text. In Common Lisp (as opposed to C and Emacs Lisp), there is a very clear separation between binary i/o (reading and writing bytes) and text i/o (reaching and writing characters), just like a number is not a character and vice versa, even though characters have an integer code.
I there, I'm new to ruby (and rails) and having som problems when using Swedish letters in strings. In my action a create a instance variable like this:
#title = "Välkommen"
And I get the following error:
invalid multibyte char (US-ASCII)
syntax error, unexpected $end, expecting keyword_end
#title = "Välkommen"
^
What's happening?
EDIT: If I add:
# coding: utf-8
at the top of my controller it works. Why is that and how can I slove this "issue"?
See Joel spolsky's article "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".
To quote the part that answers this questions concisely
The Single Most Important Fact About Encodings
If you completely forget everything I just explained, please remember
one extremely important fact. It does not make sense to have a string
without knowing what encoding it uses. You can no longer stick your
head in the sand and pretend that "plain" text is ASCII.
This is why you must tell ruby what encoding is used in your file. Since the encoding is not marked in some sort of metadata associated with your file, some software assumed ASCII until it knows better. Ruby 1.9 probably does so until your comment when it will stop, and restart reading the file now decoding it as utf-8.
Obviously, if you used some other Unicode encoding or some more local encoding for your ruby file, you would need to change the comment to indicate the correct encoding.
The "magic comment" in Ruby 1.9 (on which Rails 3 is based) tells the interpreter what encoding to expect. It is important because in Ruby 1.9, every string has an encoding. Prior to 1.9, every string was just a sequence of bytes.
A very good description of the issue is in James Gray's series of blog posts on Ruby and Unicode. The one that is exactly relevant to your question is http://blog.grayproductions.net/articles/ruby_19s_three_default_encodings (but see the others because they are very good).
The important line from the article:
The first is the main rule of source Encodings: source files receive a US-ASCII Encoding, unless you say otherwise.
There are several places that can cause problems with utf-8 encoding.
but some tricks are to solve this problem:
make sure that every file in your project is utf-8 based (if you
are using rad rails, this is simple to accomplish: mark your project,
select properties, in the "text-file-encoding" box, select "other:
utf-8")
Be sure to put in your strange "å,ä,ö" characters in your files again
or you'll get a mysql error, because it will change your "å,ä,ö" to a
"square" (unknown character)
in your databases.yml set for each server environment (in this
example "development" with mysql)
development:
adapter: mysql
encoding: utf8
set a before filter in your application controller
(application.rb):
class ApplicationController < ActionController::Base
before_filter :set_charset
def set_charset
#headers["Content-Type"] = "text/html; charset=utf-8"
end
end
be sure to set the encoding to utf-8 in your mysql (I've only used
mysql.. so I don't know about other databases) for every table. If you
use mySQL Administrator you can do like this: edit table, press the
"table option" tab, change charset to "utf8" and collation to
"utf8_general_ci"
( Courtsey : kombatsanta )