I'm losing my mind over this very simple problem. Let's consider the 2 following attempts to print the character └ from the lua interpreter:
1)
Lua 5.3.1 Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(utf8.char(2514))
2)
Lua 5.3.1 Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print("└")
└
First problem is that for some reason only option 2) actually works. But my real problem is that when I am running a script that does some printing using option 2) it actually prints the same gibberish as seen in option 1).
This leads me to my main question, why?
For info I'm simply running the script using the following command:
./lua53 path_to_my_script.lua
I feel like I am missing something very silly somewhere, yet I haven't been able to figure it out. Any help would be greatly appreciated.
Thanks!
2514 is the hexadecimal code of that Unicode character (see here).
Use
print(utf8.char(0x2514))
or
print("\u{2514}")
Related
Context
We are using NSIS 3.05 with Unicode true (this is important later).
We need to check if a certain process is running, let's call it "processToFind.exe".
In order to do that, we have been using nsProcess Plugin, which is set up correctly, found and integrated just fine.
We include Plugins from our git repository like this:
!addincludedir "C:\pathToRepo\NSIS\Include"
!addplugindir "C:\pathToRepo\NSIS\Plugins"
where pathToRepo is of course a valid path. We also tried using the default Plugin Directories (NSIS-Dir\Plugins\x86-unicode) to no avail (see below).
Documentation says, nsProcess (v 1.6) does suppport unicode. That's why we chose to use it.
NSIS UNICODE support (just rename nsProcessW.dll into nsProcess.dll)
When setting Unicode false or leaving the setting out (so default is ansi), it is working fine, too. ( = running processes found, not running processes not found )
The Installer is 32 bit, we are running on 64 bit Windows 10 machines.
Code
${nsProcess::FindProcess} "procexp.exe" $R0
MessageBox MB_OK "procexp: [$R0]"
which is defined in nsProcess.nsh (provided by plugin, not own code)
!define nsProcess::FindProcess `!insertmacro nsProcess::FindProcess`
!macro nsProcess::FindProcess _FILE _ERR
nsProcess::_FindProcess /NOUNLOAD `${_FILE}`
Pop ${_ERR}
!macroend
Problem
When having set Unicode true , nsProcess will always return 603 ("Process was not currently running").
That's the same, regardless if we try to find 32-bit or 64-bit processes.
That would be expected for 64-bit processes (they cannot be found from 32-bit installers, which is ok for us).
But I do expect it to find 32-bit processes.
Alternatives already explored:
Going through the list found at Check whether your application is running ...
Processes Plugin : Seems outdated, only sourcecode found.
"FindProcess.nsh" : Naming collision, didn't work, neither. Same symptoms.
DDE Server / Win32 Sync / Registry: Not an option.
"tasklist" command: Same symptoms. When executed in cmd, it works but not from installer.
nsExec::ExecToStack '"%SystemRoot%\System32\tasklist" /NH /FI "IMAGENAME eq ${processName}" | "%SystemRoot%\System32\find" /I "${processName}"' always returns "error". (* it's clear now why, see edit below)
"FindProcDLL" Plugin : skipped because
As of NSIS 2.46 this plugin no longer works...
Seemingly related Stackoverflow Questions explored:
NSIS : NsProcess UnExpected Output
Solution was to remove Unicode=true, which I cannot do.
NSIS- FindProc always returns 1
Uses FindProcDLL
NSIS - check if process exists (nsProcess not working)
Error was "Plugin not found" , which we do not have.
I am sure, we are making some "stupid" mistake since I cannot bring myself to believing we are the only ones with that requirement. So, any hints, suggestions and alternatives that are not listed above (or corrections to the above) are welcomed.
Edit
We totally messed up the tasklist call. As #Anders pointed out in comment: nsExec does not support pipes and on top of that, the syntax was also messed up.
Does official example work for you? It works on my machine.
Try this:
0) Delete all nsProcess.dll files (in NSIS, in your include folders, everywhere)
1) Remove line !addplugindir "C:\pathToRepo\NSIS\Plugins" from your script to use plugins in NSIS directories
2) Copy file nsProcessW.dll into **c:\Program Files (x86)\NSIS\Plugins\x86-unicode**
3) Rename file c:\Program Files (x86)\NSIS\Plugins\x86-unicode\nsProcessW.dll -> nsProcess.dll
4) Compile your script with Unicode true
I believe there is some file mismatch. To understand NSIS plugins structure see NSIS - check if process exists (nsProcess not working) .
I'm still using ANSI because I'm using some other plugins that don't have a Unicode variant, so nsProcess works for me, and I'm not sure how to answer your main question.
However, re: the tasklist command alternative you listed, the syntax isn't quite right. You're missing a closing quote after "IMAGENAME eq ${processName}["] and an opening quote before ["]${processName}" in the pipe to find.exe.
Also FYI note that if you use %SystemRoot%\System32\, a 32-bit process will be redirected to C:\Windows\SysWOW64\, and some programs have no 32-bit equivalent (e.g., pnputil). In this case, it doesn't really matter, but in any event to get around this, you should use $WINDIR\SysNative instead. You can also use ${DisableX64FSRedirection} from x64.nsh, but there are apparently some potential pitfalls there.
EDIT: Ah yes, and there's the issue with pipe and ExecToStack mentioned by Anders in the comments to the original question, requiring the call to be prefixed with cmd.exe /C
Is there a way to save my defined words to file, to continue experimenting later?
I so far found only way to copy+paste definitions from console, if they are still visible.
I am starting with forth and so I do a lot of mistakes and correct them later and I would like to save the words, I defined earlier and reuse them in next session.
Here is simple example:
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
:hello ."hello";
:1: Undefined word
>>>:hello<<< ."hello";
Backtrace:
$7F29BBAB3A00 throw
$7F29BBAC9C98 no.extensions
$7F29BBAB3CC0 interpreter-notfound1
: hello ."hello";
:2: Undefined word
: hello >>>."hello";<<<
Backtrace:
$7F29BBAB3A00 throw
$7F29BBAC9C20 no.extensions
$7F29BBAB7338 compiler-notfound1
: hello ." hello"; ok
: 2hello hello hello ; ok
2hello hellohello ok
: hello ." hello "; \ added space to end redefined hello ok
2hello hellohello ok
: 2hello hello hello ; redefined 2hello ok
2hello hello hello ok
bye
now I have working hello (with space at the end) and working 2hello (using edited hello) - lets say, I had more troubles to fix 2hello to definete form and definition of hello is out of screen now.
Is there a way, to save hello and 2hello to a file, which I
would be able use next day to make more complicated words?
could it be text file, so I would be able use some editor (say vim) to clean all bad definitions and comment those, which I want to keep?
I want to end with file welcome.fth:
: hello \ -- ; say hello and space at the end of word, to be able simply concatenate that
." hello ";
: 2hello \ -- ; repeats hello two times
hello hello ;
to be able came next day and simply continue discovering
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
include welcome.fth ok
2hello hello hello ok
\ now I can continue with learning
First, gforth saves its history in ~/.gforth-history file, which can be harvested by any text editor for my writing
Second, having history accessible with up-arrow, and having editor to save files, I can climb back and save my inputs to the file.
Does GNU FORTH have an editor?
Just set position 0 t to first line, prepend i as insert to last line of my code to put it there, insert new line before with il as insert line and fill in all other lines in this manner back to begin.
Then flush the buffer to disc and next time use this file use test.bl and load definitions with 0 load.
(Or convert the block file to normal text in editor and include test.bl it)
This I can do without leaving gforth so it works for me.
(And eventually I can somehow improve it, because it is also written in forth :)
Here is a VERY easy way to access any EXTERNAL editor in GForth.
I will explain here how it works under Linux (any version), but I guess the trick works with other Operating Systems too, it will work with Apple OSX systems.
1) Just make sure that the editor that you prefer to use with GForth is installed on your system.
VIM is already installed on Linux and OSX, and under Windows 10 you can run the BASH shell natively (Google for: 'how to install BASH on Windows 10')
I know that VIM is a very powerful editor, but I don't like it because it's NOT a screen-editor.
A great editor is MICRO, that even allowed mouse control!!
( check: https://github.com/zyedidia/micro/wiki/Installing-Micro )
2) Here is the trick:
In GForth there is a way to send a command to the Operating System:
- start GForth and type in the following command:
S" pwd" system and press the ENTER key... (pwd = Print Working Directory)
With S" pwd" system , you are sending the command 'pwd' from within GForth to the operating system,
and that command will print the 'working directory' of your Linux operating system.
Instead of 'pwd' you could of course also use another command....
Well, you guessed it:
Instead of 'pwd' you type the name of your editor ' ./micro' and presto: the MICRO editor starts up, and now you can start typing in your GForth code into the editor.
When you are ready to execute the code, just save the code into a file, like:
mycode.f
The file will be saved in the directory that was printed out on the screen in step 2 (above)
To run the code in GForth, type the following command:
include mycode.f
(you don't have to type a PATH, your file was saved in the default diretory of GForth!)
It will be added to your WORDS vocabulary, and now you can test the code.
Hope you will find this trick useful.
Enjoy writing code in Gforth with the editor of your choice !
Thanks for taking the time to read this. I'm a beginner programmer with some experience in Python, and I just started reading Zed Shaw's Learn SQL the Hard Way. In exercise 1, he has you create an .sql file type the following command in powershell:
sqlite3 ex1.db < ex1.sql
After running the following in the command-line, I receive the following error message
The '<' operator is reserved for future use.
I checked a few stackoverflow pages for answers.
Unfortunately, I cannot figure out how to bypass this error message and make a .db file from a .sql file. Apologies for any nuisances; I'm very new to stackoverflow. Any help or advice in solving this problem is greatly appreciated!
The examples that you are looking at are running inside of the bash shell on a *NIX platform. You stated that you're using PowerShell which means that the command will be different. I'm guessing it will look something like:
Get-Content ex1.sql | sqlite3 ex1.db
PowerShell is incompatible with any other shell.
If you do not know the syntax of both normal shells and PowerShell, and how to translate from one to the other, you should not user PowerShell in the first place.
Use the standard Windows command prompt (cmd.exe) instead.
I am trying to run a Perl script as a CGI script. When I run the perl script from cmd line, it runs perfectly well, but it shows the following error when I run it from my browser.
Storable object version 1.012 does not match $Storable::VERSION 1.010 at
C:/Perl/lib/DynaLoader.pm line 225.
Compilation failed in require at C:/Perl/site/lib/AsiaXMLUtils.pm line 20.
BEGIN failed--compilation aborted at C:/Perl/site/lib/AsiaXMLUtils.pm line 20
The perl script concerned has basically been designed to queue some job to a remote software.
In case it rings a bell, Line 20 in the mentioned file is :
use Storable qw(&retrieve &store);
Here are the things I have done :
I have checked the following pages on how to troubleshoot your CGI
script but haven't got around the problem.
I have checked that the perl versions are the same for my PC as well
that used for the software I am sending the script too. I guess had
that been a problem, I wouldn't have been able to run the script
from the commnad line either.
I have run a simple Perl CGI (hello world) script using the same basic html code, so I guess that means I am not putting the cgi files (or accessing them) at the wrong places.
I am running a deadline for finishing this task, and thought should ask what approach I should take to solve such a problem. I am new to Perl. Any cues to what I should read to get around the problem will be greatly appreciated. I cannot share the code anyways, since much of it is proprietary.
Storable is an XS module, which means that it has both C code in Storable.dll (or Storable.so on Unix) and Perl code in Storable.pm. That error indicates that the version of Storable.dll ("Storable object version 1.012") does not match Storable.pm ("$Storable::VERSION 1.010"). If you can run the script from the command line, that means that your webserver is either using a different version of Perl, or #INC is different, or possibly you have an extra Storable.dll in your webserver's directory.
Try to use nstore instead of store. This way, your file will be crossplatform.
Also, try to reinstall the Store module.
Here is how I was able to solve the issue, which btw wouldn't have been possible without the valuable inputs of Miguel Prz and cjm.
Regarding the Storable Module : After reading both the answers, I noticed that my pc had two versions of
Perl. I removed one of them. This got me around the "Storable object
version 1.012 does not match $Storable::VERSION" error. Sounds pretty lame, I know. But I thought I should let you know anyways. But then
I ran into another set of problems. This :
Can't locate
AJE/Constants.pm in #INC (#INC contains: C:/Perl/lib
C:/Perl/site/lib .)
From comparing with the #INC of the perl environment from the
command line (for which I found this SO post very useful), I
noticed that the #INC that my web server was using (consisting of only 2 directories as shown above) did not include
many of the directories in the #INC of the command line perl environment. This is where cjm's words came back to me! I then used use lib to add those files in my
perl script and that solved the problem!
Thank you for all the help!
I compiled some Matlab code on Centos 5.
I try to run it like this:
run_cnaseq006.sh /projects/rcorbettprj2/mutationSeq/MCR/v714/ "/home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m"
------------------------------------------
Setting up environment variables
---
LD_LIBRARY_PATH is .:/projects/rcorbettprj2/mutationSeq/MCR/v714//runtime/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//bin/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/os/glnxa64:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/server:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64/client:/projects/rcorbettprj2/mutationSeq/MCR/v714//sys/java/jre/glnxa64/jre/lib/amd64
??? Error using ==> run at 65
/home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m not found.
However, I can easily see that the file does exist:
ll /home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m
-rw-r--r-- 1 rcorbett users 3 Aug 13 09:10 /home/rcorbett/slx_service_rc/etc/cnv_test_data/CNV_test/config.m
I tried different quotes, and no quotes, but I can't figure out why it won't execute the file. The Code works fine as uncompiled matlab code, so something funny is happening after compilation that affects the ability to identify the file.
EDIT: run_cnaseq006.sh is the auto generated shell script for running my compiled code. It is about 40 lines, so doesn't copy well into here. However, I can say it is just a wrapper to make sure all the libraries are loaded when I run my compiled code. All the compiled code I have get pretty much the exact shell script wrapper.
I was pointed to this link:
http://blogs.mathworks.com/loren/2008/08/11/path-management-in-deployed-applications/
The "run" command uses path management functions like "cd". According to the above article such activities are unsupported in compiled applications, and can create unpredictable results.
I resigned to using an alternate approach to define my runtime variables by reading the file with getline and using "eval" to load my variables into memory.