I have had the following problem which both Google and the Python documentation cannot aid me.
Essentially, I want to be able to perform redirection at the command-line level using the subprocess library as in the following (using a shell script) so I can perform operations in that directory:
Example:
#!/usr/local/bin/python
from subprocess import call
call("cd", "/usr/local/bin")
However, it doesn't change to that directory. Does anyone know what I am missing? I will be most appreciative of any insight that anyone can give on this.
Thanks!
The shell started by subprocess.call() changes directory. And then it exits. Your script does not change directories. Try os.chdir() instead.
Related
I'm having a frustrating, but seemingly simple problem. I was recently pushing some files to github and now ls has started listing directory contents recursively when I use the basic command ls. Though, it only appears to do so in my Google Drive folder. It functions normally when used in directories outside of Google Drive. I'm not sure if it is connected to something I was doing with git or completely unrelated. I had been working on a github project in my Google Drive when I noticed the issue.
The output of type ls in the Google Drive directory and outside of it is:
ls is hashed (/bin/ls)
Does anyone have any input on how I can get ls to function 'normally' again? I'm not sure how I could've changed its function but it appears I must have. Let me know if there is additional information that would help in understanding the problem.
Thank you in advance
Your ls might be aliased (perhaps in your ~/.bashrc; look inside file that with your editor) by your interactive shell (or it might become a bash function). Check with type ls (using the type builtin).
Use \ls or /bin/ls to get the real ls program.
If your shell is bash, be sure to read the chapter on bash startup files.
Try also using stat(1) and/or some other shell (e.g. zsh, sash, ...).
SOLVED:
I'm not sure why this was occurring, but the issue seems to be related to having updated a Shiny app through rsconnect() in R. I closed RStudio and now the ls command is working properly again in all directories. I have no idea why this would occur and didn't think that would be related at all. Thanks for the troubleshooting help!
I am writing some automation to control a simulator. I am also using WebDriverAgent along with openatx python bindings in pycharm. There are some things that are fast using cURL in a bash script and some methods that are stronger in the python solution. I want to use a mix of both. I have imported bashSupport into pycharm and would like to execute a bash script from within my file system of the project.
I have tried subprocess import and os but it doesn't seem to be executing my script. Here is an example:
import subprocess
subprocess.call(['launch_wda.sh'])
with device.session('com.apple.mobilesafari') as app:
print app.orientation
app(label="Address").tap()
app(label="Address").set_text("facebook.com \n")
the launch_wda.sh is in my file structure of the project. Is my syntax incorrect or am I missing something else?
Try these changes:
Add ./ before script name. As this could be some path related issue.
Try adding shell=True if you are not under Posix system and you do not have something like this #!/bin/sh as a first line of your bash script.
Last but not the least, check the permissions for the bash script.
Hope this helps.
I have a relatively strange problem with bash shell scripts and tcl scripts, invoked from within the shell scripts.
In perspective, I have a shell script that generates some other shell scripts, as well as tcl scripts. Some of the generated shell scripts invoke tcl scripts with tclsh command.
The files are created and stored in a directory, also created by the initial shell scripts, that generates the files and the folders where these are to be stored.
The problem is with the generated shell scripts, which invoke tclsh to run a tcl script. Even if the files are generated and the shell scripts have the permissions to be executed, the response from the shell is that the tcl file embedded in the shell script cannot be found.
However, the file exists and I can open it with both vi and gedit, RHEL 9.0 or Centos 5.7 platforms. But, when I take the same shell script out of the created directory, this error does not appear. Can you please suggest any idea? I checked also directory permissions, but they seem ok. I also checked the shell script for extra characters, but I did not find anything.
It's hard to tell what exactly is going wrong from your description; you leave out all the information actually required to diagnose the problem precisely. However…
You have a tclsh on your PATH, but your script isn't running despite being chmodded to be executable? That means that there's a problem with your #! line. Current best practice is that you use something like this:
#!/usr/bin/env tclsh
That will search your PATH for tclsh and use that, and it's so much easier than any of the alternative contortions.
The other thing that might be causing a problem is if your Tcl program contains:
package require Tcl 8.5
And yet the version of Tcl used by the tclsh on the path is 8.4. I've seen this a number of times, and if that's your problem you need to make sure that the right Tcl rpm is installed and to update your #! line to this:
#!/usr/bin/env tclsh8.5
Similarly for Tcl 8.6, but in that case you might need to build your own from source as well and install that in a suitable location. (Tcl 8.6 is still only really for people who are specialists.)
(The issue is that RHEL — and Centos too, which tracks RHEL — is very conservative when it comes to Tcl. The reasons for this aren't really germane to this answer though.)
Could the problem be as simple as the fact that you don't have "." in your PATH? What if instead of calling your script like "myscript.tcl" you call it like "./myscript.tcl" or "/absolute/path/to/myscript.tcl"?
Im trying to automatically run a script using Cygwin via CMD. I basically created a BAT file that goes to the directory and executes an .SH file. SH files are accosiated with Cygwin, and I tried something like "cygwin update.sh" in the command line. But all it really does is open Cygwin. I want Cygwin to automatically run the script file. Is there any easy way to do this, I've been trying to find but can't. Thank you!
You'll want to call the shell script with a particular shell, e.g. bash.
When having Cygwin open, call which bash to figure out where the binary is located. Cygwin also comes with tools that can convert paths between Cygwin and Win32 form, which is pretty helpful in cases like yours.
There is one other thing that may work, depending on your setup. There is an environment variable named PATHEXT which declares file extensions that are deemed "executable" by CMD. This can be used to your advantage, if Windows is configured so that the shell's "open" verb executes the correct shell for the file extension .sh (in your case).
Good luck.
From Cygwin Terminal, read man mintty. Try something like the following from a Windows Command Prompt:
c:\cygwin\bin\mintty --hold always --exec /cygdrive/c/path/to/bash/script.sh
I also found this!
http://rothmanshore.com/2011/01/26/kick-off-a-cygwin-script-from-a-windows-bat-file-with-a-different-working-directory/
I didn't quite understand it at first, but then it worked as I wanted it. Just if anyone knows, is there a way to make the script run without the CMD window open?? Thanks
I searched google but couldn't find an answer to this rather simple question. I have a python script that has the hash-bang (#!) on the first line:
#!/usr/bin/python
However, what if this is run on a computer with python in /bin/python or /usr/local/bin/python, or some other place? There has to be a better way to set the interpreter for a shell script. It should be possible to set it via $PATH, as that will know where to find python if it's installed on the system.
Use env.
#!/usr/bin/env python
It's not bulletproof, but it covers more cases than /usr/bin/python.
Use
#!/usr/bin/env python
env is virtually always in /usr/bin, and will execute any program in the PATH.
Some people prefer to start with:
#!/usr/bin/env python
Not sure that this is a vast improvement as you're now assuming that python is in the path and that it's the right version, but it's an option.