When I try to run a .sh script on an SSH instance on Google cloud, I get this error:
bash: abc.sh command not found
This runs fine when I run it on the Google shell. I tried setting 'PermitUserEnvironment yes' in the sshd_config file but this did not change the output.
From my reading on similar issues, it seems as though I should be setting some other PATH variables but I'm not sure which ones these are.
The issue was solved running the command with the path.
/path/to/file.sh
You were not able to run the command because bash was trying to locate that command inside the location specified by PATH enviroment variable since you were not specifying the path.
Future people reading could find as well useful information here regarding possible causes.
Related
I apologize in advance if this question has already been answered. I've looked at several posts and have yet to find the info to resolve my issue.
I'm trying to work with Kaggle's API to download some data sets. I've installed Kaggle with pip3 and have downloaded the Kaggle.json file and moved it to c:/users//appdata/local/programs/pythoncodingpack/lib/site-packages/kaggle. I did not specifiy this particular path, this is where pip3 automatically saved the kaggle folder. The .json folder is definitely in there, but when I try to run the API command "kaggle datasets download -d victorsoeiro/netflix-tv-shows-and-movies" I get the error included in the title.
What I have noticed is that there is an executable file called kaggle.exe on the path c:/users//appdata/local/programs/pythoncodingpack/scripts/kaggle.exe. I was wondering if maybe the computer was finding that file and stopping before finding the kaggle folder on the ./lib/site-packages/kaggle/ path.
I have tried granting permission with the chmod 600 command on the ./kaggle/kaggle.json path and I have tried including the whole path when executing the command. Nothing I've done so far has resolved the error when I try to run the API command. Can anyone help out?
Trying to get the sidekick image built and having some issues. Is there any documentation other than the README.md file?
My current problem is with getting the JRE requirement working but there are others. The page says "download Oracle JRE and place it inside the working directory. Optionally if you have a company wide distribution url, use that one at a later step." and the help says "Java (JRE) download url or path inside working directory". Have not been able to get this to work.
I went to the JRE link provided and was presented with options to download a rpm file or a tar.gz file. Which is expected (was unable to get either one working)?
It says to place the file in the "working directory" but not sure where exactly. Tried in sidekick folder and in sidekick/jre both without success no matter what I used after the -j command. Is this just the path or should the filename be included as well? Can I get an example?
I'm running this script using my login but noticed the output folder is being created with root user and group. I see no indication that this should be run with sudo. What is the correct way to run this script?
Using debug, I see the function "download if not cached". Can I save these files (JRE, Bamboo jar file, etc.) somewhere so I don't have to worry about downloading them? If so, where should they go? Looks like I might have a problem with the wget to d/l the jar file so would like to just be able to place all these in a folder and be done with it.
It looks like the major problem is the script didn't clean up after itself if it fails. The issue was the first time it failed then that caused subsequent issues as the output folder was already there. Removing this directory between each attempt help.
As for the correct syntax for the -j JRE option I manually downloaded the JRE and placed in a folder called per-build-container/sidekick/stuff/. For the command line it is not just the path but the file name as well (the tar.gz and not the RPM). For my case it was
-j stuff/jre-8u251-linux-x64.tar.gz
Note I also ran the script as sudo. Wasn't stated but seemed to work OK.
Another issue I ran into was the download of the agent jar file. There is a redirect in the wget file that was not working for us. I ended up editing the script and replacing the Altassian based url with the redirected one.
This addresses all the issues I ran into with the initial question.
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.
I want to change the build dir of team city build agent to:
E://MY_PROJECT_SVN
While installing the build agent I set the same but it diaplays C://buildAgent/work in TeamCity web ui due to which my build fails.
My buildAgent.properties file shows
workDir=E\:\\MY_PROJECT_SVN
And buildAgent.dist.properties file shows
workDir=E://MY_PROJECT_SVN
But I get following error when I run team city
Failed to start MSBuild.exe. Failed to find project file at path:
C:\BuildAgent\work\3ac16e0b4e3af05b\Modules\SIM5.sln
Because of wrong working dir
The buildAgent.dist.properties is indeed just an example, but the solution is something you almost had; you need to put this into the buildAgent.properties:
workDir=E:/MY_PROJECT_SVN
Update:
It should be noted that on TeamCity 7.0 the workDir seemingly can't be on a separate disk; it runs most of the way through the build and then fails. However, using a junction to point from the local (default) folder to the E: drive will work. The tempDir can be pointed to a remote disk though.
The file buildAgent.dist.properties is not used, it is just an example. So don't worry about the contents of that file.
What you have set in buildAgent.properties is what matters. What is happening for you is the agent is reverting to the default location for the working directory.
This means that for some reason it is not able to read or parse the buildAgent.properties file. Make 100% certain that the entire file has no errors in it.
https://confluence.jetbrains.com/display/TCD8/Build+Agent+Configuration
Making any change to this file and saving it should cause the build agent to reboot automatically and reload the new config once it has restarted.
http://blog.jetbrains.com/teamcity/2007/10/configuration-files-editing-without-teamcity-restart/
To build on paul-f-wood's answer:
Teamcity 9.1.6 also has the "feature" where the work directory cannot be on a different drive. I tried several permutations of the temp and work dir, and the only ones that stuck were with the work dir on the same drive as the root teamcity folder. However as paul said, using a junction works like a charm.
cmd: rm C:\BuildAgent\work
cmd: mklink /J C:\BuildAgent\work E:\MY_PROJECT_SVN
I am getting started with Meteorjs. I'm a windows user so I downloaded the windows installer package Release 0.7.0.1-win2. I use gitbash for my command line interface and can't get it to recognize meteor. I get the error "sh.exe": meteor: command not found". It works fine in windows command line but I prefer gitbash.
How do I get meteor to work with gitbash?
I have the perfect answer for you since I literally just solved the issue myself.
First of all make sure meteor works in the default windows command prompt. Next open git bash and check if the following command works:
cmd //c meteor
This runs the command meteor as if you were in the command prompt.
Next step is to set up an alias in git bash so you don't have to type that out each time.
Open git bash and enter the following:
vim ~/.bashrc
this will open/create the bashrc file in VIM, press i to insert and type the following:
alias meteor="cmd //c meteor"
Save and exit vim by first pressing the Esc key then press the ":" key. Now you should be able to enter commands in VIM. Type "wq" and press enter which will write into your .bashrc file and exit vim.
Almost there! Now that you are back in git bash, all you need to do is point to your .bashrc file by entering the following:
source ~/.bashrc
Now you will be able to run meteor commands straight from git bash! Hope that helped!
Here's the fix:
The problem is because of .bat files not being handled properly by
MinGW
Go to this directory - C:\Users[your username]\AppData\Local\.meteor
You should see a meteor.bat file there. Create a new file called "meteor" (without any extension and ""). Open it with notepad and paste the following:
#!/bin/sh
cmd //c "$0.bat" "$#"
save the file and now run git bash. You should be able to use meteor command in git bash.
Details
To run a *.bat command from MinGW's MSYS shell, you must redirect the execution to cmd.exe, thus:
cmd //c foo.bat [args ...]
The foo.bat command file must be in a directory within $PATH, (or you must specify the full path name ... using slashes, not backslashes unless you use two of them for each path name separator). Also, note the double slash to inform cmd.exe that you are using its /C option, (since it doesn't accept the -c form preferred by the MSYS shell.
If you'd like to make the foo.bat file directly executable from the MSYS shell, you may create a two line Bourne shell wrapper script called simply foo alongside it, (in the same directory as foo.bat), thus:
#!/bin/sh
cmd //c "$0.bat" "$#"
(so in your case, you'd create script file meteor alongside meteor.bat).
In fact, since this wrapper script is entirely generic, provided your file system supports hard file links, (as NTFS does for files on one single disk partition), you may create one wrapper script, and link it to as many command file names as you have *.bat files you'd like to invoke in this manner; (hint: use the MSYS ln command to link the files).
Credits to: Keith Marshall on SO and rakibul on Meteor Forums
It shouldn't be too hard - you just need to make sure that the meteor.bat file is in your executable. Check with echo $PATH from the bash console if it is already there.
For me, the meteor 0.7.0.1-win installer appended meteor's folder to the path automatically. However, you can add it manually with:
export PATH=$PATH:/path/to/user/folder/AppData/Local/.meteor
(On CygWin my user folder is at /cygdrive/c/Users/adam - I'm not sure what the equivalent path would be on git bash).
If you like, append that line to your ~/.profile to make sure meteor gets added to the path when the console opens.
Finally, on Windows the executable file is meteor.bat. I made a symbolic link to the filename meteor, just so I wouldn't have to type the .bat:
cd /path/to/user/folder/AppData/Local/.meteor
ln -s meteor.bat meteor.
Please have a look at the issue https://github.com/sdarnell/meteor/issues/18
I would suggest maybe creating a trivial wrapper script or alias that invokes LaunchMeteor.exe with the original arguments.
After more research on google I see that there isn't an implemented way to do this yet. The guys at meteor are working on it and accepting pull requests if you have a solution. The conclusion I came to is to use Vagrant and virtualbox to set up a ubuntu vm for meteor development. You can find info at this site: http://win.meteor.com/ on how to install virtual machines and provision to work with meteor.