I'm fairly sure the answer to the title is 'no'. However, I'd like some suggestions because I'm not able to gracefully solve this seemingly simple problem. Here's what I'd like to do in a single rule that works unmodified in Linux and Windows:
Run a shell command that produces a certain directory as part of its output. The name of the shell command is identical in Linux and Windows, so it works in both places unmodified.
Rename the directory using pathlib or some other Python module so it works transparently in Linux and Windows.
That's it!
Here's what I have come up with already which I don't want to do because they seem clunky:
Run the executable and do the rename in a shell. For this I need to make custom command lines based on which platform I'm on. (Linux 'mv' vs. Windows 'rename') Yuck.
Make another rule that runs automatically and does the rename after this rule. This is a little better but still doesn't seem "right".
I'll bet there's an elegant solution, but what is it?
Yes. There are two ways to execute a command in the shell, depending on the use case:
A shell: line in a rule. Can't be combined with other Python code.
A shell() command that can be used with other Python code in a rule's run: line
Related
I'm currently working in Linux, and I know you can use Run Process to run certain applications, but I was wondering if there's a possible way to have my script running, open command line, input, for example: "clean" which in my case processes a few functions in my bash.rc. That would be extremely helpful in my automation right now.
Well essentially, what I did was I created a separate .sh executable file. Opened my .bashrc and copied my functions / aliases into my .sh file using the gedit editor. Then from my Robot Script, I used the Run Process command (I don't have my exact code at the moment) and called my executable file.
I have a .cmm file which helps in debugging of Qcomm chipsets.
This file has a line : cd ../../../../../modem_proc
When I run this same cmm file using T32 GUI, it runs fine and does the work. But when I am trying to run the same file using windows command line using,
C:\T32\bin\windows64>t32mqdsp6.exe -c C:\T32\config.t32 -s D:\path\to\xxx.cmm
Following error is thrown in T32: syntax error in B::cd ../../../../../modem_proc
What am I missing here? I have no hands-on experience with T32 what-so-ever.
The problem probably results from different working directories. Type
PRINT OS.PWD()
in the GUI and add it to the top of the script. I'd suspect they are different.
Don't use working directory relative paths, instead use paths relative to the script, e.g.
CD ~~~~/../../../../modem_proc
The four tilde (~) symbols mean "directory of the currently executed script". There's still a possible issue with this solution when using multiple GUIs and the intercom, but for most use-cases this should be OK.
When starting TRACE32 (up to build 99518) without option "-s", it starts a default script t32.cmm form your TRACE32 installation directory. But t32.cmm is not executed, when "-s" is used.
So probably your t32.cmm is changing your working directory. If so you can fix the issue by adding the line
DO ~~/t32.cmm
to the top of your script xxx.cmm.
See also https://www.lauterbach.com/frames.html?help_autostart.html
The default working path is also set by the TRACE32 configuration file. That is the file passed with "-c". So if your are using a different configuration file than C:\T32\config.t32 when starting your TRACE32 GUI the normal way, then you should use that configuration file also when starting TRACE32 from the command line.
To get the path of the configuration file usually used, start TRACE32, execute command AREAand then command PRINT OS.PCF()
Furthermore dev15 is probably right here https://stackoverflow.com/a/53671657/4727717:
Use paths relative to the PRACTICE script (cmm-file) by starting each path with four tildes.
Sorry for the noob question. I just downloaded CAM::PDF along with Strawberry for Windows, and trying to do find/replace from the command line. Ran buidinstalldeps to get all needed prereqs.
I'm trying to run changepagestring.pl from command line. But idk how to reference the file location and have it put the output file for me in a specified location:
changepagestring.pl master-exch-manual.pdf "as shown in Figure" figure output.pdf
My goal is to replace "see above figure" with "figure" in this file. But it's in a different directory than the one I'm in, C:\Users\Me\Doc\CAM-PDF-1.60\
So how do I run and do all this from the command line. I've seen the help file with example, but I get this:
CAM::PDF from command shell with PL file not recognized
There are a few possible solutions. The easiest one from the directory you mentioned is:
perl -Ilib bin/changepagestring.pl ...
Alternatively, if you run the usual Perl install commands from that folder, then changepagestring.pl should be included in your usual path
perl Makefile.PL
make install
Alternatively^2, you can use the "cpan" tool to automate the download, build, test and install steps in one go:
cpan install CAM::PDF
I have installed redis onn linux.
redis sever started correctly however when I try to start redis-cli I get this error
bash: redis-cli: command not found
file redis-cli output is
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x5fe1c6d3da13df88f2ea826ac762f088c29b81d5, not stripped
I don't know what's the reason
but when I run the using this command
/usr/local/bin/redis-cli it works
but when I run redis-cli from the /usr/local/bin/ folder I get the error
bash: redis-cli: command not found
Looks like some path issue
If you built from source and you're in the default redis-stable directory that contains the source, you should be able to start the cli by running:
./src/redis-cli
It seems like redis-cli is present, reading your answer. Check this with which redis-cli.
I've installed redis on several linux machines, normally it goes very smooth. I guess you've run into a special case.
Here's my thoughts:
It might be a dynamic linking issue.
So check the headers with dump -H -X64 redis-cli.
In the headers, you can see which shared objects it is trying to find. There might be a shared object from another package in the way, for example a 32-bit only one. Ugly, and wrong, but it happens.
Use the ldd runtime dependency checker to see what those headers actually result in on your system. Install it when not present. Then simply run ldd redis-cli.
Now you've figured out what's wrong, you can do several things.
1) Remove the conflicting package, if possible.
2) Use the LIBENV environment variable, to set the search path for shared objects, prior to starting the process
3) Use the -blibpath linker option at compile/link time to alter the header, giving it a different search path. The -bnolibpath could also help you.
4) Patch the header afterwards. There are tools for this. This is generally not the preferred way to go.
Hope this helps, TW
Edit:
Although make, make test, and make install were always fine, the server install script install_server.sh was always a bit buggy. This has just been fixed in 2.8.8. I recommend using the latest version.
Edit 2:
The OP's problem turned out to have nothing to do with dynamic linking, it was a simple PATH issue. I leave the answer as is, for historical purposes.
This maybe happening because the executable isn't in path. In order to solve this, you can try copying redis-cli on the /usr/local/bin/ folder with this command:
sudo cp /src/redis-cli /usr/local/bin/
I installed Ruby on Rails 3 using bash on OSX Lion.
When I wanted to use zsh and do a "rails -v" command I had "Rails is not currently installed on this system".
I just do not understand why. To me it's like "you can access all the files you want with bash not with zsh".
If I want to switch to zsh, will I have to install one more time Rails? delete the old one?
Is it secure and clever to use two shells when developing Rails applications?
What are your best practices?
Thanks in advance.
PS: I am new to programming and my installation is working fine. I even created one app.
EDIT: If you encounter the same problem I would encourage you to read the second answer first to get the rationale then the first one. Thanks to both of them.
While you are running bash, type at the command line echo $PATH.
Now start up your zsh command line, and type echo $PATH.
I bet the Rails path is not included in your zsh, right?
Look in your $HOME dir for .bash* files. See which one has the Rails PATH added.
Find your zsh .* env files and copy/paste the line you found above into the approriate file.
When I say .bash* and .* files, I mean hidden files in your home dir that you'll only find by doing ls -la. If you find a .profile file, that would be a good place to insert this.
I hope this helps.
P.S. as you appear to be a new user, if you get an answer that helps you please remember to mark it as accepted, and/or give it a + (or -) as a useful answer.
I just do not understand why. To me it's like "you can access all the
files you want with bash not with zsh".
As shellter said, you must have directories added to your path in order to run commands from the command line. For more information on PATHs take a look at the Intro to Linux guide. I know you are not using Linux but that section (and lots of others) is very much applicable.
If I want to switch to zsh, will I have to install one more time
Rails? delete the old one?
No, see note on paths above and take a look at the guide.
Is it secure and clever to use two shells when developing Rails
applications? What are your best practices?
It's not really something special to use two shells at once. It depends what you do in each. I often have 6 and 7 shells open, not all for the same thing. That is really up to you and how you work. The number of shells you use is more of a workflow thing than a "best-practices" issue.
I normally have 3 shells open when I do RoR work. One running autotest in the background, one running rails -server, and one where I actually edit files and run emacs. But again, this is not best practice as it is workflow. Do whatever makes you effective.
The only trouble you could get into occasionally running two shells is say, for example, you open a file in one and delete it in another. However, when you do this it is typically very obvious.
PS: I am new to programming and my installation is working fine. I
even created one app.
For Rails, I found this tutorial very helpful.
Also, you said you were new to programming. I don't know if this is the case, but I would suggest starting with basic Ruby, before jumping into Perl. Although the tutorial I linked above covers Rails-flavored Ruby.