I am trying to get different paths in Red language. If I cd to /myfolder and run following command:
/myfolder$ /path/to/red.exe /path/to/myscript.red
How can I get these 3 paths from code in script?
I tried:
system/options/path ; Gives path/to/myscript
system/script/path ; Gives none
call/output "pwd" outstr ; Gives path/to/myscript
what-dir ; Gives path/to/myscript
I am able to get only one path. How can I get path of red.exe and path of current working directory (In Red language- not Rebol)?
Note: this is related to my question on Rebol at What-dir reporting own directory as current directory in Rebol
In Rebol (2 & 3), this is how you can get those three paths:
system/options/boot ;; /path/to/red.exe
system/options/path ;; /myfolder
system/script/path ;; /path/to/myscript.red
At this moment only system/options/boot in Red matches what Rebol does here.
From the GUI Console:
boot string! {C:\ProgramData\Red\gui-console-2017-11-30-4300.exe}
home none! none
path file! %/C/ProgramData/Red/
script none! none
cache file! %/C/ProgramData/Red/
From the cli:
boot string! "C:\ProgramData\Red\console-2017-11-30-4430.
home none! none
path file! %/C/Users/Old%20Man/desktop/
script none! none
cache file! %/C/ProgramData/Red/
Using the GUI Console:
system/options/boot ; Red binary
system/options/path ; current dir
system/options/cache ; Red default dir "home"
system/options/boot is a string!, so you'll have to convert it with:
to-red-file system/options/boot
Related
Hello I have been trying to get user input and store it in a variable, and then use that variable in a CMD. ALL of this in a DXL script!
Take a glance into the code I have tried this but still not working.
string wheretosave = ""
DB exBox = create "Get Path"
DBE stringInn = field(exBox, "ADD Path where to save:", "", 80)
void doGet(DB exBox) {
wheretosave = get stringInn
print wheretosave "\n"
system("cmd.exe /C cd /d wheretosave & dir & PAUSE")
}
apply(exBox, "Get", doGet)
show exBox
to add "wheretosave" to a string, use
system("cmd.exe /C cd /d " wheretosave " & dir & PAUSE")
But I think the system call does not work. When I start a command line and do a command
cmd.exe /C cd /d d:\temp & dir & PAUSE
then I get the dir of the original directory.
#root: ADDITION: my problem was that I did not have a directory d:\temp on my PC...
But after reading your comment, it seems the point was not understood.
To be more precise:
First: there is no interpolation in DXL. If you want to create a string which contains a) some fixed characters, b) the content of a variable (here: wheretosave) and c) some more fixed characters, you have to use a < space > to concanate the three parts. So, do it like this: string s1 = "fixedtexta" wheretosave "fixedtextb".
Second: If the fixed characters contains a quotation mark then you have to escape it with a backslash. So, this example would become to string s2 = "fixedtexta\"" wheretosave "\"fixedtextb" to get fixedtexta"hello world"fixedtextb if wheretosavecontains hello world
BUT your example is even more difficult.
Third: cmd.exe /C takes only one parameter. So, if you want to do more than one command in the cmd subshell, you have to surround all the commands with enclosing quotation marks cmd.exe /C "cmd 1 & cmd 2 & cmd 3" The way you wrote it would have translated to
create a subshell which does a "cd /d", end the subshell
in the main shell (which is still in the original directory), do a "dir"
in the main shell, do a "pause"
Fourth: In DOS, if you have a quotation mark inside a string, you have to escape it with a second quotation mark.
All in all the command you are looking for is
string wheretosave = "d:\\temp x" // or get stringInn in your example
system("cmd.exe /C \"cd /d \"\"" wheretosave "\"\" & dir & pause\"")
Try providing the full path and apply Mike's correction. Using "C:\Windows" works as expected (for me): the cmd shows the content of my Windows folder on drive C.
Unix shell ksh
I created a file list and am currently trying to copy each file to their correct path.
(mylist)
-1111
-2222
-3333
-4444
-5555
current directory
/sample/dir/unknown/
-1111fileneeded.txt
-2222fileneeded.txt
-3333fileneeded.txt
-4444fileneeded.txt
-5555fileneeded.txt
-6666dontneed.txt
-7777dontneed.txt
-8888dontneed.txt
...etc
The first 4 characters of each file matches with their correct path to where they need to go.
/sample/dir/1111/
/sample/dir/2222/
/sample/dir/3333/
/sample/dir/4444/
So here is what I currently have..
for i in `cat mylist`
do echo "$i"
find /sample/dir/unknown/mylist*
this is where I am kinda stuck and trying to figure out what needs to be done to have each file moved into their correct directory.
This should work
#!/bin/ksh
while IFS=\| read -r line; do
dir=`echo $line | cut -c 2-5`
mv "$line /sample/$dir/$line"
done > filelist.txt
IFS is escape special char, just in case.
cut -c 2-5 is taking all char from 2 to 5 (because there is a dash at the start of your file name)
Let me know if there is something else you don't understand.
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
Here's an odd little problem that's led me to post my first question on SO. I am using wkhtmltopdf to convert an HTML document to a PDF as part of a Rails app. To do so, I am rendering the Rails web page to a static HTML file in a temp directory, copying a static header, footer and images to the same temp directory, then executing wkhtmltopdf using "system".
This works perfectly in Development and Test environments. In my Staging env, it does not. I suspected permissions at first, but the first couple of parts of that process (creating the HTML static files and copying them to the directory) are working. I can run wkhtmltopdf from the command line in that temp directory and get the expected outcome. Finally, I ran wkhtmltopdf via both "system" and backticks through the Rails console in staging environment, and here's what I get as output:
> `wkhtmltopdf --footer-html tmp/invoices/footer.html --header-html tmp/invoices/header.html -s Letter -L 0in -R 0in -T 0.5in -B 1in tmp/invoices/test.html tmp/invoices/this.pdf`
Loading pages (1/6)
QPainter::begin(): Returned false ] 10%
Error: Unable to write to destination
Error: Failed loading page http://tmp/invoices/test.html (sometimes it will work just to ignore this error with --load-error-handling ignore) => ""
Notice that last bit. I'm pointing to local files, but it's looking for them via http. OK, I think, maybe I need to be explicit and feed it the file:// protocol so it doesn't look for http. So I try this:
> system("wkhtmltopdf --footer-html file://Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/footer.html --header-html file://Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/header.html -s Letter -L 0in -R 0in -T 0.5in -B 1in file://Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/test.html file://Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/this.pdf")
Loading pages (1/6)
Error: Failed loading page file://library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/test.html (sometimes it will work just to ignore this error with --load-error-handling ignore)
=> false
Notice that this one fails with a lowercase "l" on Library. What the heck? (And no, it doesn't get any better with the recommendation to ignore the error with that switch.)
Any ideas? Is there a Rails or Ruby setting that would cause system commands to get rewritten? Is there an option I can add to wkhtmltopdf to make sure it loads from local file? I'm quite baffled. Thanks!
I have had success when using the absolute file path (notice the extra slash after the file://)
wkhtmltopdf --footer-html file:///Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/footer.html --header-html file:///Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/header.html -s Letter -L 0in -R 0in -T 0.5in -B 1in file:///Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/test.html file:///Library/Server/Web/Data/Sites/intranet-staging/current/tmp/invoices/this.pdf
This is the same on windows
Unix path
file:///absolute/path/to/file
Windows path
file:///C:/absolute/path/to/file
In last 0.11 whicked-pdf i found one bug
Example
C:\Ruby193\lib\ruby\gems\1.9.1\gems\wicked_pdf-0.11.0\lib>wicked_pdf.rb
Line 198 I change from:
options[hf][:html][:url] = "file://#{tf.path}" to options[hf][:html][:url] = "file:///#{tf.path}" - (change // to ///)
After change whicked-pdf again worked.
Take a look at the wicked_pdf gem.
You can add a PDF mime type and then whatever page you want pdf'd, just tack on a .pdf to the URL.
I am using this in prod and it works quite well.
No need to call wkhtmltopdf directly.
I installed rbenv through homebrew, and now I don't know why path_helper put ~/.rbenv/shims at the end of the path instead of the beginning. And most importantly, how did path_helper get this information?
According to the man page of path_helper, it reads entries from /etc/paths and from files in /etc/paths.d. But I cannot find the string ".rbenv/shims" there.
~% cat /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
~% ls -la /etc/paths.d
total 0
drwxr-xr-x 2 root wheel 68 Jun 21 03:16 .
drwxr-xr-x 107 root wheel 3638 Sep 10 09:59 ..
~% /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/gordon/.rbenv/shims"; export PATH;
I suspect that your .bash_profile or .bashrc is adding
.rbenv/shims to your PATH, and that is running at some point before
path_helper is invoked during the shell start-up.
The man page for path_helper opens with:
The path_helper utility reads the contents of the files in the directo-
ries /etc/paths.d and /etc/manpaths.d and appends their contents to the
PATH and MANPATH environment variables respectively.
The crucial point here is that the path_helper utility is intended to
add contents to an existing PATH setting, not replace them. (And in
actuality, what it really does is prepend contents, not append them,
which matters for PATH variables...)
So, if I start out with an entry on my PATH, the setting generated by
path_helper will ensure that entry continues on the PATH it generates.
% echo $SHELL
/bin/bash
% uname
Darwin
% /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"; export PATH;
% PATH="" /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"; export PATH;
% PATH=foo /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo"; export PATH;
Note that foo has been included in my PATH in the last line, even though
the contents of /etc/paths and /etc/paths.d/* have not changed.
At the same time, the path_helper utility also seems to be careful not
to produce paths with duplicate entries; it removes duplicate entries
after concatenating /etc/paths and /etc/paths.d/* and the current
PATH.
This latter detail can be especially confusing since it can cause
entry reorderings compared to the original PATH setting (!).
Below are some examples of this behavior: The first case shows a duplicate foo being removed. The second and third case illustrate entry reordering: the generated PATH is the same in both cases, but in the third case, the /usr/bin entry has been moved from in-between foo and bar to the front of the PATH. (This duplicate-entry removal seems to be based on just simple string-matching on the pairs of entries, as illustrated by the fourth case below where the string /usr/bin/ remains between foo/ and bar.)
% PATH=foo:foo /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo"; export PATH;
% PATH=foo:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo:bar"; export PATH;
% PATH=foo:/usr/bin:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo:bar"; export PATH;
% PATH=foo/:/usr/bin/:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo/:/usr/bin/:bar"; export PATH;
Finally, to give credit where credit is due:
While all of the command sequences above are the result of my own investigations, I was originally inspired to look into the behavior of path_helper after reading the note here,
which pointed out that path_helper reuses the PATH environment variable set by the parent process.
The path_helper man page is incorrect. The man page says path_helper is appending /etc/paths.d onto the PATH. But actually, path_helper is APPENDing /etc/paths.d onto the list from /etc/paths and then effectively PREPENDing that result onto actual pre-existing PATH (as well as purging PATH of overridden duplicates from that list).
To be exact, speaking only of PATH for instance, what it does is:
read the list of paths in the file /etc/paths
APPEND onto it the lists of paths in the files in the directory /etc/paths.d
mutate the PATH variable to remove any items in the list
APPEND onto the list the value of the mutated PATH variable
Save this list as the new PATH
To rephrase this in pseudocode, what it's doing is:
NEWPATH = Read(/etc/paths)
NEWPATH = $NEWPATH +append+ Read(/etc/paths.d/*)
PATH = $PATH -minus- $NEWPATH
NEWPATH = $NEWPATH +append+ $PATH
PATH = $NEWPATH
What's treacherous about this is that, if you are manually configuring your PATH, it's probably in order to add components that override system path components. If path_helper gets called when you don't expect it, then it will undo your changes by putting the system-wide path components ahead of your path components.
How would path helper get called unexpectedly? For instance, it gets called by /etc/zshenv, which is called every time you start a zsh shell, whether it's a subshell, or a zsh instance called from another app like emacs, or whatever.
I've written it in more detail as an OpenRadar bug report on path_helper.