I use the following to grep in the current directory and all subdirectories:
grep -r 'some text' */*
This works fine in Cygwin, but when I configure Windows cmd emulators like Console2 or ConEmu to use Cygwin, the command does not work:
grep: */*: Invalid argument
Is there some technical reason why */* does not port to these applications?
Is there another way of grepping across the current directory and subdirectories?
Many thanks
*/* is not correct for the current directory in unix style terminal emulators, use ./* or even just . would work.
Using . or ./* may be unnecessary but might get around the invalid argument problem.
Related
Hey in Jenkins I'm trying to run robot framework tests:
with command python3 robot -d results mytestsuite.robot, and it has some line to open chrome browser, but the message in log shows me typical: WebDriverException: Message: 'chromedriver' executable needs to be in PATH. Please see...
Everything works ok locally, and I'm not sure which PATH jenkins wants to use so my questions are:
why do I have to input python3 instead of python (with just python in command it tells me that robot is not found)
why chromedriver is not found, and how to set it up (in what PATH and how) to make it work
Is it possible to set jenkins up to use other drivers ex. geckodriver?
My jenkins job env looks like this:
#!/bin/bash
echo $JENKINS_HOME
which python3
echo $PATH
outputs:
/Users/MYUSER/.jenkins
/usr/bin/python3
/Users/MYUSER/.jenkins/tools/chromedriver:/usr/bin:/bin:/usr/sbin:/sbin
Ok so I've fixed it with:
export PATH=/Library/Frameworks/Python.framework/Versions/3.9/bin/:$PATH
this is the location where I have chromedriver locally.
in the build shell execute but is there a way to make it more permanent (I mean not to use it every time it runs build?)
I have a problem when using the SLIP in Contiki. The port only can be changed to /dev/ttyUSB1 in /contiki/tools directory with the command sudo ./tunslip6 -s /dev/ttyUSB1 aaaa::1/64 -v6
However, when I want to make a connection at /contiki/examples/ipv6/rpl-border-router directory, with the command make connect-router, it will then change back to /dev/ttyUSB0
May I know what is the problem?
Thank you.
The command make executes the recipes contained in the file Makefile. If you look within that (in your example folder) you will find the recipe calling tunslip:
connect-router-cooja: $(CONTIKI)/tools/tunslip6
sudo $(CONTIKI)/tools/tunslip6 -a 127.0.0.1 $(PREFIX)
you can change the command there and add -s /dev/ttyUSB1.
I'm trying to setup a new app with postgresql so I can deploy with Heroku. However, when I run the app using 'rails server' my welcome to rails screen gives this error:
PG::Error
could not connect to server: Permission denied Is the server running
locally and accepting connections on Unix domain socket
"/var/pgsql_socket/.s.PGSQL.5432"?
I'm sure this is the same issue as is covered here:
Repairing Postgresql after upgrading to OSX 10.7 Lion
But the fix by John Wang doesn't work.
I've tried adding 'export PATH=/usr/local/bin:$PATH' to the .bash_profile, .bashrc and .zshrc, none of which change the outcome. Calling which psql always returns /usr/bin/psql.
What am I doing wrong here? Any help would be much appreciated!
edit
Running /usr/local/bin/psql gives the same error and running echo $PATH gives:
/opt/local/bin:/opt/local/sbin:/Users/dave/.rvm/gems/ruby-1.9.3-p194/bin:/Users/dave/.rvm/gems/ruby-1.9.3-p194#global/bin:/Users/dave/.rvm/rubies/ruby-1.9.3-p194/bin:/Users/dave/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/dave/.rvm/bin
What happens if you run your locally installed psql directly?
/usr/local/bin/psql ...
If that works then it's the path you need to change. You can just try running the export in a terminal, then which psql. If that doesn't pick up the right psql then check the export worked with
echo $PATH
I'm not sure which .xxrc file you'll need to update then - not got a mac to hand I'm afraid, but at least you'll know the command will work.
Oh - I keep several different versions of PostgreSQL around and find it useful to have some aliases set up:
alias psql90='/usr/local/pgsql90/bin/psql -p 5490'
alias psql84='/usr/local/pgsql84/bin/psql -p 5484'
alias pg_dump90=...
Your $PATH is just a list of directories to check separated by ":". It starts /opt/local/bin rather than /usr/local/bin and if you look further along you'll see /usr/bin coming before /usr/local/bin. So - we need to do two things:
Find out which psql we actually want
Make sure we can edit our PATH
Firstly - find your postgresql.conf file and check what port you are running on. There are three items of interest: listen_addresses, port and unix_socket_directory. Then we'll see if there's a socket there.
ls -a <your unix_socket_directory>
You should see a "file" something like ".s.PGSQL.5432" where the 5432 is the port number from your config file. If there's no such file, it's not running and it's time to get it running. You may need to change the port number in the config file if it matches Apple's existing usage.
Then find what psql installations exist
find /usr -type f -name psql
find /opt -type f -name psql
Try and figure out which one you need, perhaps add --version to help.
Then, let's see about editing your PATH. You must have some changes in your settings file anyway, so let's see if we can find where that setting is.
grep -l 'local/bin' ~/.*rc
That should list filenames containing local/bin - have a look and see if they are editing your PATH.
I'm writing a script, and I need to look up a command on the user's $PATH and get the full path to the command. The problem is that I don't know what the user's login shell is, or what strange stuff might be in their do files. I'm using the bourne shell for my simple little script because it needs to run on some older Solaris platforms that might not have bash.
Some implementations of "which" and "whence" will source the user's dot files, and that isn't really portable to all users. I'd love a simple UNIX utility that would just do the basic job of scanning PATH for an executable and reporting the full path of the first match.
But I'll settle for any /bin/sh solution that is stable for all users.
I'm looking for a solution that is better than writing my own /bin/sh loop that chops up $PATH and searches it one line at a time. It would seem that this is common enough that there should be an reusable way to do it.
My first approximation of the "long way" is this:
IFS=:
for i in $PATH; do
if [ -x $i/$cmd ]; then
echo $i/$cmd
fi
done
Is there something simpler and portable?
The answer seems to be the 'type' built-in.
% /bin/sh
$ type ls
ls is /bin/ls
Maybe the whereis command will work for you?
whereis -b -B `echo $PATH | sed 's/:/ /g'` -f [commands]
e.g. on my computer, this works:
whereis -b -B `echo $PATH | sed 's/:/ /g'` -f find man fsc
And results in:
find: /usr/bin/find
man: /usr/bin/man
fsc: /opt/FSharp-2.0.0.0/bin/fsc.exe /opt/FSharp-2.0.0.0/bin/fsc
One caveat from the whereis man page:
Since whereis uses chdir(2V) to run faster, pathnames given
with the -M, -S, or -B must be full; that is, they must begin
with a `/'.
This question is answered in details here: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then. Bottom line: use command -v ls.
While trying to install a build server I've run into a funny problem where all cygwin commands can be run from a DOS box but sometimes do not work when called from make. What's even more weird is some make targets, like 'clean', work and others, like 'all', do not.
Here's a representative makefile extract. The quoting has hosed the formatting but tabs are where they should be, trust me:
.PHONY: all
all: update_autoconstants
/usr/bin/rm -f $(OBJ_DIR)/myfile1.txt
rm -f $(OBJ_DIR)/myfile2.txt
.PHONY: clean
clean:
rm -f $(OBJ_DIR)/*.*
Notice that in 'all' one rm call has a full path and one has no path. Also notice that clean's rm call has no path.
To this the response to a 'make -C makefile all' is:
/usr/bin/rm -f ../../obj/myfile1.txt
rm -f ../../obj/myfile2.txt
make: rm: Command not found
make: *** [all] Error 127
ie. the full path works, the no-path does not. What then starts my head spinning is the 'clean' target in make with no path works fine. it's not just cygwin commands, make can't find the compiler either. It seems pretty clear that somewhere the path has been hosed, although the environment variable PATH is set, but only in make - this works fine from a DOS prompt.
C:\>cygpath --unix c:\programme\cygwin\bin\rm
/usr/bin/rm
The machine is running Windows Server 2003 German language in a virtual machine on VMWare ESX, the cygwin install was done yesterday, installed in c:\programme\cygwin\ and everything else is clean vanilla Windows installation.
Any ideas? Thanks in advance.
Not really so much of a solution as a workaround - we made all the makefiles use absolute paths to the exe files they need which is in any case a bit nicer than searching a path and taking what you find.
To perhaps save someone some Googling commands in cygwin's bin directory can best be called:
CYGWIN_EXE_PATH = /usr/bin
RM = $(CYGWIN_EXE_PATH)/rm.exe
.PHONY: clean
clean:
$(RM) -f $(OBJ_DIR)/*.*
And similarly files in the program files directory like this:
COMPILER_DIR = "$(PROGRAMFILES)/TASKING/c563 v3.6r1"
Hope that helps.
I've had the exact same thing.
rm not being found by make from within a makefile.
My workaround was to run the makefile from within bash. Previously I was just running make from a windows cmd box. This cured the problem for me, but created new issues. The permissions of some files that were created during the make had very odd permissions being set.