Search Results

Search found 3 results on 1 pages for 'n0rd'.

Page 1/1 | 1 

  • Perl strings internals

    - by n0rd
    How does perl strings represented internally? What encoding is used? How do I handle different encodings properly? I've been using perl for quite a long time, but it didn't include a lot of string handling in different encodings, and when I encountered a minor problem that had something to do with encodings I usually resorted to some shamanic actions. Until this moment I thought about perl strings as sequences of bytes, which did fit pretty well for my tasks. Now I need to do some processing of UTF-8 encoded file and here starts trouble. First, I read file into string like this: open(my $in, '<', $ARGV[0]) or die "cannot open file $ARGV[0] for reading"; binmode($in, ':utf8'); my $contents; { local $/; $contents = <$in>; } close($in); then simply print it: print $contents; And I get two things: a warning Wide character in print at <scriptname> line <n> and a garbage in console. So I can conclude that perl strings have a concept of "character" that can be "wide" or not, but when printed these "wide" characters are represented in console as multiple bytes, not as single "character". (I wonder now why did all my previous experience with binary files worked quite how I expected it to work without any "character" issues). Why then I see garbage in console? If perl stores strings as character in some known encoding, I don't think there is a big problem to find out console encoding and print text properly. (I use Windows, BTW). If perl stores strings as multibyte sequences (e.g. using same UTF-8 encoding), why is it done this way? From my C experience handling multibyte strings is PAIN.

    Read the article

  • Autodetect console output encoding in perl

    - by n0rd
    I have a perl script that prints some information to console in Russian. Script will be executed on several OSes, so console encoding can be cp866, koi8-r, utf-8, or some other. Is there a portable way to detect console encoding so I can setup STDOUT accordingly so the text is printed correctly?

    Read the article

  • Can't open COM1 from application launched at startup

    - by n0rd
    I'm using WinLIRC with IR receiver connected to serial port COM1 on Windows 7 x64. WinLIRC is added to Startup folder (Start-All applications-Startup) so it starts every time I log in. Very often (but not all the time) I see initialization error messages from WinLIRC, which continue for some time (couple of minutes) if I retry initialization, and after some retries it initializes correctly and works fine. If I remove it from Startup and start manually at any other moment it starts without errors. I've downloaded WinLIRC sources and added MessageBox calls here and there so I can see what happens during initialization and found out that CreateFile call fails: if((hPort=CreateFile( settings.port,GENERIC_READ | GENERIC_WRITE, 0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0))==INVALID_HANDLE_VALUE) { char buffer[256]; sprintf_s(buffer, "CreateFile(%s) failed with %d", settings.port, GetLastError()); MessageBox(NULL, buffer, "debug", MB_OK); hPort=NULL; return false; } I see message box saying "CreateFile(COM1) failed with 5", and 5 is an error code for "Access denied" error according to this link. So the question is why opening COM-port can fail with such error right after booting Windows and proceed normally few seconds or minutes later?

    Read the article

1