The git-blame man page does not mention -m, but only -M. Running git-blame on a source file with a very long commit history, once with -m and again with -M, shows identical output (also using -CCC in both executions). Is this just a mistake in the man page, or is expected behavior whereby if the user uses a lower-cased version of an option, git-blame interprets it as the upper-cased version of the same option?
Related
I am using Cleartool in a build script to update a dynamic view's config spec. The script is a perl script being run on Cygwin. The Cleartool command successfully changes the config spec of the dynamic view, but it does not update the view itself. In the script we use the following commands:
cleartool setcs -tag <view_name> <config_spec_file1>
cleartool catcs -tag <view_name>
The catcs command outputs the expected config spec, and opening up the view's config spec in ClearCase Explorer shows the expected config spec. It is not until we open up the config spec, and simply hit apply, that we see the expected view files (we don't change anything in the config spec, we just open, apply, and close).
We have also tried forcing the view to stop/start after the setcs command, but that didn't work either.
I would expect that the setcs command alone would be enough, as the documentation says that's all that is needed.
setcs documentation
If possible, avoid Cygwin, and run the perl script in a simple CMD session.
You have some resources for getting Unix commands without having to use Cygwin.
Gnu On Windows includes 100+ Unix commands,
Git for Windows has more than 200 of them, plus a msys2 modern bash shell.
If you really have to use Cygwin, add at least a cleartool ls (done in the vob of the view whose config spec just was updated).
An ls should force the files to be updated.
I am trying to backup a db of postgresql and I want to use pg_dump command.
I tried :
psql -U postgres
postgres-# pg_dump test > backup.sql
But I don't know where the output file goes.
Any help will be appreciated
I'm late to this party, but I feel that none of the answers are really correct. Most seem to imply that pg_dump writes a file somewhere. It doesn't. You are sending the output to a file, and you told the shell where to write that file.
In your example pg_dump test > backup.sql, which uses the plain or SQL format, the pg_dump command does not store any file anywhere. It just sends the output to STDOUT, which is usually your screen, and it's done.
But in your command, you also told your shell (Terminal, Command prompt, whatever) to redirect STDOUT to a file. This has nothing to do with pg_dump but is a standard feature of shells like Bash or cmd.exe.
You used > to redirect STDOUT to a file instead of the screen. And you gave the file name: "backup.sql". Since you didn't specify any path, the file will be in your current directory. This is probably your home directory, unless you have done a cd ... into some other directory.
In the particular case of pg_dump, you could also have used an alternative to the > /path/to/some_file shell redirection, by using the -f some_file option:
-f file --file=file
Send output to the specified file. This parameter can be omitted for file based output formats,
in which case the standard output is used.
So your command could have been pg_dump test -f backup.sql, asking pg_dump to write directly to that file.
But in any case, you give the file name, and if you don't specify a path, the file is created in your current directory. If your prompt doesn't already display your current directory, you can have it shown with the pwd command on Unix, and cd in Windows.
Go to command prompt and directory postgresql\9.3\bin.
Example
.
..
c:\Program files\postgresql\9.3\bin> pg_dump -h localhost -p 5432 -U postgres test > D:\backup.sql
...
After above command enter User "postgres" password and check D:\ drive for backup.sql file
In my situation (PostgreSQL 9.1.21, Centos 6.7), the command
runuser -l postgres -c 'pg_dump my_database > my_database.sql'
saved the file here:
/var/lib/pgsql/my_database.sql
Not sure if that is true for other Linux dists, CentOS and/or pgl versions. According to the answer post by the asker of this question, this is true, but other users said the backup file was in the current directory (a situation different of most people reading this thread, for obvious reasons). Well, I hope this can help other users with the same problem.
P.s.: if that's not the path for your situation, you can try (in Linux) to find it using the below command (as stated by #Bohemian in the comments of this question), but this can take a while:
find / -name 'my_database.sql'
EDIT: I tried to run the analogous command in Ubuntu 12.04 (it works on Ubuntu 18.04):
sudo -u postgres pg_dump my_database > my_database.sql
And in this case the file was saved in the current directory where I ran the command! So both cases can happen in Linux, depending of the specific dist you are working
For Linux default dump path is:
/var/lib/postgresql/
If you are not specifying fully qualified paths, like:
pg_dump your_db_name > dbdump
then in Windows it stores dumps in current user's home directory. I.e.:
C:\Users\username
If you use linux (except centos)
sudo su - postgres
pg_dump your_db_name > your_db_name.sql
cd /var/lib/postgresql
ls -l
Here your'll see your_db_name.sql file
In pgadmin 4 for a Mac, assuming dump is successful you can click on "More Details" you will see a box that says "Running command:" in that box you will see /Applications/pgAdmin 4.app/Contents/SharedSupport/pg_dump --file "path/to/file" where path to file is the destination of storage.
After doing
psql -U postgres
Using the command
\! pg_dump -U postgres humaine > C:\Users\saivi\OneDrive\Desktop\humaine_backup1.sql
The output file would go where the path at the right is specified
In the server (Ubundu/Centos) the path of backup file will be
/var/lib/pgadmin/storage/
Below is the OS specification.
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
I am using following command to take the backup of postgresql database.
pg_dump -U postgres -Fc <db_name> > /var/lib/postgresql/backup-20230123.dump
If storage file path has been provided explicitly, in that case, the database dump will be generated to that place only.
For windows, provide folder path where you want to download the dump.
I have been using the cake command on my linux server for 2 years. but now im trying to move to a new server and some how the cake command gives back the error: No such file or directory
even if i give the entire path to the cake command file chmod 777 it stil wont work.
I found the solution: All I had to do is use the program dos2unix the cake file for CakePHP 2.4.2 has wrong endings when you download it with Ubuntu 13.10
I used the following command:
sudo dos2unix /path/to/cake/lib/Cake/Console/cake
I also have this problem on some servers and never figured out why this happened. I suspect the so called "shebang" might not be set correctly for every Linux distribution (e.g. if the cake script stars with #!/usr/bin/env bash, but you don't use bash on your server or your distribution doesn't have the env binary in that path, it might fail on that. This is just a theory though, as I said I never really figured it out, nor did I invest much time in investigating.
Although, what I always use as a fallback is simply calling the cake.php script (from the app folder) instead, like:
php Console/cake.php -app `pwd` bake
That never lets me down. The -app pwd bit is to tell the shell that your current directory is your app directory, so the shell can find all your files.
The REAL solution to this is to change the End-of-Line (EOL) characters to Unix format, instead of MsDos. So I guess this error will only occur if you worked in Windows.
Anyway, teh mighty
SOLUTION:
(1) Open app/Console/cake file using any text editor that allows changing of EOL characters e.g. NotePad++.
(2) In NotePad++ click:
Edit -> EOL Conversion -> Convert to Unix format
(3) Save the file and upload it to the server. Now if you navigate to the CakePHP app directory using command like:
cd /usr/share/nginx/html/cakeproject/app
...you should be able to run Console/cake without any problems and see standard output (basically help commands).
Hope this helped you!
I encountered the same problem as well, but the top answer reminded me of a similar problem I faced before: https://stackoverflow.com/a/5514351/1097483
Basically, instead of using dos2unix or installing it, you can open the file in vim, do
:set fileformat=unix
And save it.
In some versions it's possible to install cake using sudo apt-get install cakephp-scripts.
After instalation, you coud access bake anywere simple by typing bake
I would like to know how to either ignore upgrading certain ports or unmark them as "outdated".
This is motivated by certain ports failing to upgrade, while I wish to upgrade all the rest. I know about sudo port install -n, which allows one to install a port without upgrading port dependencies, as in the case of mongodb requiring an older (not the current) version of theboost libraries, but this is not applicable here.
For example:
$ sudo port list outdated
gdb #7.5 devel/gdb
py27-scikits-image #0.7.1 python/py-scikits-image
As gdb#7.5 fails to update, I would just like to upgrade the others, ie. py27-scikits-image, without going thru the whole sudo port list outdated | awk '{print $1}' | grep -v gdb | xargs sudo port upgrade pipeline.
Much appreciated.
I would advise to create a local portfile for gdb with a lower version number.
Create a local portfile repository: howto
Copy the gdb portfile directory (a directory called "gdb" containing the file "Portfile" and directory "files") into your local portfile repository
Change the version number in the portfile to e.g. 0.0
Run portindex in your local portfile repository
The local portfile overrides the one downloaded from the default port repository. The low version number makes macports think your version of gdb is up to date.
I hope this can help.
BTW: you can do sudo port upgrade outdated and not gdb
I recently updgraded MacPorts from 1.9.2 to 2.0.3. Since then, I've lost the ability to run as sudo.
sudo: can't stat /opt/local/etc/sudoers: No such file or directory
sudo: no valid sudoers sources found, quitting
Unsure if these are related, but I'm wondering what the best course of action is at this point.
port installed returns
sudo #1.7.4p2_0
sudo #1.7.7_0 (active)
Further investigation suggests I've installed MacPorts' sudo without an accompanying /opt/local/etc/sudoers file. I've managed to create such a file using visudo, copying the content of /etc/sudoers, chmod to 0440 and ownership to root:wheel.
I guess the question now is whether I should use MacPorts' sudo or uninstall it? And how did I end up with installing the MacPorts' sudo?
Not a Mac man myself, but have a look at this page:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/sudoers.5.html
...and also a look at the man page for visudo, which is used to edit the sudoers file:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/visudo.8.html#//apple_ref/doc/man/8/visudo