When I power up the terminal it reads:
username at 34 in ~
Im not sure what the 34 refers to. Is there a way I can figure out what's going on? I had previously cloned a dotfile.
It is really hard to answer this question because of the lack of information. For instance:
Which shell are you using: bash, zsh, ...?
Do you use a shell framework like Oh My ZSH! or
What was the dotfile you cloned?
Here is my guess. A possible cause of the problem may be in the dotfile: you have cloned a (let's say) .bashrc from somebody else having this prompt configuration and the operation has overwritten your .bashrc.
If you are using bash, try running echo $PS1 to get the prompt configuration. Your prompt looks something like
\u at \H in \w
\u is the username
\H is the hostname (I'm guessing, I don't know what 34 stands for)
\w is the working directory
Is there a way to change gwan's default behavior of naming your site with the pound character and virtual hosts with the dollar sign. So many of my development tools have consistent problems accessing directories with # and $ in the file name. Shell scripts have problems, ftp clients have problems... I'm hoping there is a way to change those default characters to something else. Or is there some linux change I need to make for it to be more friendly? I'm not a linux expert by any stretch, but I have seen several threads talking about how using those characters is discouraged.
I'm sure there must be pros and cons to using those characters, I just don't know what the pros are.
EDIT *
As it turns out, the problem was simply permissions. My 0.0.0.0_8080 directory and below was root:root My tools were logged in as a different user. Guess I was too wrapped up in the use of $ and # to see the real problem.
For that to be possible it would break one of the most interesting aspects of GWAN: no configuration files.
And it would create a point of failure.
To access the directories on a terminal just escape the beginning of the virtual host path with '\' like
cd \$yourvirtualhost.com
This also works on sftp commands. If you want a graphics tool use FileZilla it works perfectly for me.
The answer by Paulo was informative, but I wanted to put closure on the actual question so the answer appears to be that you cannot change the default characters of $ or # for the host and virtual host names. The problems I described in the question had nothing to do with gwan, but with my own misconfigured user/groups. My 0.0.0.0_8080 directory and below was root:root My tools were logged in as a different user. Guess I was too wrapped up in the use of $ and # to see the real problem.
fwiw
I noticed that I can't combine --traditional options with the other one letter other options such as -i for example.
For example, when I have this as the first line in my octave .m file
#!/usr/bin/octave --traditional
Then it work. Octave starts ok and runs the script.
But when I try
#!/usr/bin/octave --traditional --silent --norc --interactive
It does not work. Error from octave. does not understand the options.
When I try
#!/usr/bin/octave --traditional -qfi
Also error. But this
#!/usr/bin/octave -qfi
works.
The problem is that --traditional does not have a one letter short cut like all the other options. This is the options I see
Options:
--debug, -d Enter parser debugging mode.
--doc-cache-file FILE Use doc cache file FILE.
--echo-commands, -x Echo commands as they are executed.
--eval CODE Evaluate CODE. Exit when done unless --persist.
--exec-path PATH Set path for executing subprograms.
--help, -h, -? Print short help message and exit.
--image-path PATH Add PATH to head of image search path.
--info-file FILE Use top-level info file FILE.
--info-program PROGRAM Use PROGRAM for reading info files.
--interactive, -i Force interactive behavior.
--line-editing Force readline use for command-line editing.
--no-history, -H Don't save commands to the history list
--no-init-file Don't read the ~/.octaverc or .octaverc files.
--no-init-path Don't initialize function search path.
--no-line-editing Don't use readline for command-line editing.
--no-site-file Don't read the site-wide octaverc file.
--no-window-system Disable window system, including graphics.
--norc, -f Don't read any initialization files.
--path PATH, -p PATH Add PATH to head of function search path.
--persist Go interactive after --eval or reading from FILE.
--silent, -q Don't print message at startup.
--traditional Set variables for closer MATLAB compatibility.
--verbose, -V Enable verbose output in some cases.
--version, -v Print version number and exit.
I am mainly interested in running octave code that is compatible with Matlab, so I'd like to use this --traditional option to make sure I keep the code compatible with Matlab in case I need to run the same code inside Matlab as well.
Or may be I can "turn on" this compatiblity mode once octave starts using a different command?
I am using GNU Octave, version 3.2.4 on Linux.
thanks
I don't think this is really an octave problem, per se. The Unix shebang notation in general is somewhat limited. I don't know the exact limits off the top of my head, but I'm pretty sure many implementations aren't happy if you add more than one option to the shebang line, which seems to be your problem.
Using a wrapper script is probably the canonical way to get around such problems.
To address your question of combining short and long options, Unix conventions don't allow for this. You could consider patching octave to add a short option for --traditional, if this is feasible for you. Alternatively, I'd imagine there's a way to specify the traditional behavior in the user or system-wide Octave configuration file, but this might not be that helpful if you need the script to work on systems you don't control.
I have such section in my ~/.hgrc config file
[auth]
repo.prefix = ssh://hguser#192.168.132.72/repos
repo.key = /home/zerkms/.ssh/mercurial-repo/id_rsa
But when I write:
hg clone ssh://hguser#192.168.132.72/repos/rps .
mercurial still requires password to enter.
What have I done wrong?
To prevent obvious questions:
Yes, there is a valid key in the specified path and it works if use it with ssh-agent.
My question is how to work with keys in [auth] section.
The following works for me (probably a new setting since the question was asked):
Add to hgrc:
[ui]
ssh = ssh -C -i ~/.ssh/id_rsa-mercurialkey
-C to enable compression, -i to specify identity file. If the key is loaded into ssh-agent, I don't get asked again for passphrase.
auth isn't for SSH. The key needs to be loaded in another way. If it were just ~/.ssh/id_rsa it would be done automatically, as it's not you may need to do something to register it. Using ~/.ssh/id_rsa is the easiest way normally - put the contents of ~/.ssh/id_rsa.pub in ~/.ssh/authorized_keys on the target machine and you're ready.
I use GVIM on Ubuntu 9.10. I'm looking for the right way to configure GVIM to be able to edit remote files (HTML, PHP, CSS) by for exemple ftp.
When i use :e scp://username#remotehost/./path/to/file i get: error detected while processing BufEnter Auto commands for "*":E472: Command failed.
When i open a file on remote via Dolphin or Nautilus, i cannot use other files with NERDTree.
Finally when i edit on remote a file via Dolphin the rights are changing to access interdit.
So how to use GVIM to edit remote files like on my localhost?
I've found running the filesystem over ssh (by means of sshfs) a better option than having the editor handle that stuff or running the editor itself over an ssh tunnel.
So you need to
apt-get install sshfs
and then
sshfs remoteuser#remotehost:/remote/path /local/mountpoint
And that will let you edit your remote files as if they were on your local file system.
To make it even smoother you can add a line to /etc/fstab
sshfs#remoteusername#remotehost:/remote/path /local/mountpoint fuse user,noauto
For some reason I find that I have to use fusermount -u /local/mountpoint rather then just umount /local/mountpoint when experimenting with this. Maybe that's just my distro.
Recently I've also noted that the mounting user must be in the fuse group. So:
sudo addgroup <username> fuse
An other popular option of course, would be to run vim (rather then gvim) inside a GNU Screen session on one machine and connect to that session via ssh from wherever you happen to be. Code along all day at work and in the evening you ssh into your office computer, reattach to your gnu screen session and pick up exactly where you left off. I used find the richer color palette to be the only thing I really missed from gvim when using vim, but that can actually be fixed thanks to a fork of urxvt that will let you customize the entire 256 position color palette, not just the 16 first positions of the palette that most terminal emulators will let you customize.
There is one way and that is using the remote host's copy, using SSH to forward the X11 client to you, like so:
user#local:~/$ ssh -X user#host
...
user#host:~/$ gvim file
The latter command should open gvim on your desktop. Of course, this relies on the remote host having X11 / gnome / gvim installed in the first place, which might not be the solution you're looking for / an option in your case.
Note: X11 forwarding can be a security risk.
In order for netrw to work seamlessly, I believe you need to not be in compatibility mode.
Try
:set nocompatible
then
:edit scp://host/path/to/file
Try this
:e scp://username#remotehost//path/to/file
Note that the use of // is intentional after remotehost it gives the absolute path of your file
:)
http://www.celsius1414.com/2009/08/19/how-to-edit-remote-files-with-local-vim/
The vim tips wiki has an article on this, Editing remote files via scp in vim.
EDIT: Key authentication is not necessary for opening files over ssh. Vim will prompt for password.
It would be useful to note if netrw.vim was loaded by vim when it started.
:echo exists("g:loaded_netrwPlugin")
For opening files over ssh, you need your local machine's public key in the server's authorized keys. Following help section in vim documentation explains it pretty well.
:help netrw-ssh-hack
Quick way to export public key would be by using ssh-copy-id (if available).
ssh-copy-id user#host
And have a look at netrw documentation for network file editing over other protocols.
:help netrw
HTH.
According to the docs BufEnter is processed after the file has been read and the buffer created, so my guess is that netrw successfully read the file but you have a plugin that assumes the file is on the local filesystem and is trying to access it, e.g. to run ctags.
Try disabling all your plugin scripts except the default Vim ones, and then editing the file.
Also, try editing a directory to see if netrw can read that - you need to put the / on the end so that netrw knows it is a dir.
About your command, :e scp://username#remotehost/./path/to/file : note that with netrw, scp is taken relative to your home directory on that remote host. To avoid home-relative pathing, drop that "."; ie. :e scp://username#remotehost//path/to/file .
to accomplish this on windows download/install the Dokan library and Dokan SSHFS, which are the first and last links on this page.
I didn't think you were going to be able to directly edit a remote file using GVIM running locally. However, as others have pointed out, this is defintiely possible. This looks very interesting; I will check this out. I will leave the rest of my post up here, in case it is useful to anyone else, as an alternative method. This method will work even if you don't have SSH access to the file (ie, you only have FTP, or S3, or whatever).
You may get that effect, though, by tying GVIM into a graphical file transfer application. For example, on OS X, I use CyberDuck to transfer files (FTP, SFTP, etc). Then, I have it configured to use GVIM as my editor, so I can just double-click on a file in the remote listing, and CyberDuck will download a copy of that remote file, and open it in GVIM. When I save it in GVIM, CyberDuck uploads the file back to the remote host.
I'm sure that this functionality is not unique to CyberDuck, and is probably present in most nicer file transfer utilities.