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
Related
I have written a backup script that uses expect to automate rsync.
To make sure all files get backed up, I use rsync's --rsync-path="sudo rsync" option.
#!/bin/bash
set -e
expect <<- DONE
spawn rsync --rsync-path="sudo\\ rsync" -uav myuser#example.com:/home/myuser/ /backups/home/myuser
expect ":"
send -- "mypassword\r"
expect eof
DONE
This does not work as intended. I get the following error message:
bash: sudo rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
I have seen similar questions with respect to using spaces in a rsync command line, and have added single quotes, double quotes, and escape backslashes here and there, but nothing has worked yet.
How do I make "--rsync-path with spaces" work within an expect script?
The problem is that you've got this:
--rsync-path="sudo\\ rsync"
Inside Expect/Tcl, this is seen as:
--rsync-path="sudo rsync"
And, because Tcl's quoting rules are not the same as bash's, that then uses "sudo rsync" with the double quotes as the command to send to the remote side. Which confuses things terribly. The correct fix is to omit the double quotes; the (backslash-quoted) backslash will ensure that it all gets into spawn as one argument, and gets sent to the other side correctly.
I really don't like using HEREdocs with Tcl. Too many things can go weird when different sorts of quoting interact. It's much better to use a single script in the real target language, since then you can use variables to make things clearer:
#!/usr/bin/env expect
set remoteRsync "sudo rsync"
set from myuser#example.com:/home/myuser/
set to /backups/home/myuser
set pass "mypassword"
spawn rsync --rsync-path=$remoteRsync -uav $from $to
expect ":"
send -- "$pass\r"
expect eof
exit
This makes the structure of the code much simpler to see, and easier to debug. The bit with /usr/bin/env at the start is just a way to avoid having the bash wrapper.
And no, those variables won't need quoting at use. Tcl is not bash.
You can't use --rsync-path to do that, since what you want is word-splitting, i.e. something the shell does.
So how can you run a command that runs a command by specifying a single pathname?
On the remote system, write a script wrapper susync doing the sudo (don't forget to chmod 755):
#!/bin/sh
exec /path/to/sudo /path/to/rsync "$#"
and use
spawn rsync --rsync-path=/path/to/susync ...
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
My ultimate goal is to do telnet to a router and interact with it. The following expect script does not help me at all. The router does not have any user id or pasword. it is automatic login.
Expect file code.
set iptotelnet "10.x.x.x"
spawn telnet $iptotelnet
sleep 10
expect ">" #this is because initially the prompt will be >
sleep 10
send "enable\r" # this should change the prompt from > to #
sleep 10
expect "#"
sleep 10
interact
sleep 10
exit
However, I get the following error.
send: spawn id exp4 not open
while executing
send "enable\r".
This is not just with telnet, i get the same error with any other command also.
please help me.
Your script has no major issues with it, not that would cause spawn to fail like that. (The comments you have would cause problems, but are trivially fixable by using ;# instead of #.) Therefore your problem lies elsewhere (well, with very high probability).
I see that you are trying to control telnet with Expect on Windows. Alas, telnet is a special case that can't be controlled this way — Expect on Windows uses the system debugging facilities to intercept terminal output, but this doesn't work for executables that have special system permissions set, and telnet is one of the programs for which this is true — so you need another approach. The simplest is to get plink.exe (which is really PuTTY for terminals/automation) and to use that (in “telnet” mode) instead of telnet.
Probably you can't use # comments in send command line.
Try same but without comment in send string.
It happens to me too. And it has been resolved.
I try to automatically telnet a server in the Cygwin on Windows.
But the Microsoft telnet installed in Windows won't work in a Cygwin shell
If you got the response below, this is the source of your problems type:
$ which telnet
/cygdrive/c/WINDOWS/system32/telnet
There are two solutions:
1. For Cygwin x86, just simply install the package "inetutil" which includes telnet command.
2. For Cygwin x86_64, currently(2013-09-09) the "inetutil" hasn't been port to 64bit, so I use the plink.exe which is part of PuTTy instead
Right now, if I want to run mysql, I have to do /Applications/MAMP/Library/bin/mysql -u user -ppass... I'd be a happy camper if I could just do mysql -u user -ppass.... Been googling around, but haven't been able to find anything... Have a feeling I'm using dumb search terms, so if anyone here knows how to do this, that'd be awesome...
you can either add /Applications/MAMP/Library/bin/ to your bash PATH variable (edit your .bash_profile, find the line with export PATH=... and add here the path to MAMP bin folder) , or maybe create an alias with alias mysql='/Applications/.../bin/mysql' (also in your .bash_profile).
Add:
export PATH=$PATH:/Applications/MAMP/Library/bin/
to your ~/.profile
It will take effect next time your profile is initialized (I'm not sure when that is under OS X, it might be when you start your terminal application, it might be when you log in)
It depends what shell you're using. You should be able to add /Applications/MAMP/Library/bin/ to your path:
export PATH=${PATH}:/Applications/MAMP/Library/bin
Mac OS uses bash by default. Just add this line to your .bashrc.
Execute . ./.profile to restart your profile.
I'm having a rather strange problem with zsh. When I start up my shell, everything - functions, environment vars, aliases, etc. - all work fine. I've created the following function and sourced it in zsh:
clean()
{
path=/tmp
for i in ${path}/*; do
echo $i
done
}
Running clean in the terminal works as expected, in that it prints out all the files in /tmp/. Afterward, however, trying any command - for example, ls - produces this:
zsh: command not found: ls
I have several other functions that work just fine, which leads me to believe that somehow, that loop is causing the problem. At any rate, this is very frustrating and I would sincerely appreciate the community's eyes. Thanks!
The problem is assigning the path variable - since zsh has that variable reserved (in addition to PATH), overwriting it removes the ability for the shell to find any command.
The correct answer, of course, is to use a variable other than $path:
local_path=/tmp
for i in ${local_path}/*; do
echo $i
done
I guess it overwrites the variable path, which is the one used to find commands. That's why it doesn't find commands anymore.
I dugg for hours to find this again. Zsh offer a nice trick to remove duplicates from PATH-type variables, a bit out of topic, but may be useful :
typeset -T PYTHONPATH pythonpath
typeset -U pythonpath
the first line bind PYTHONPATH colon separated string to zsh array
the second remove duplicates