Unlike ssh, scp uses the uppercase P switch to set the port instead of the lowercase p:
scp -P 80 ... # Use port 80 to bypass the firewall, instead of the scp default
The lowercase p switch is used with scp for the preservation of times and modes.
Here is an excerpt from scp's man page with all of the details concerning the two switches, as well as an explanation of why uppercase P was chosen for scp:
-P port Specifies the port to connect to on the remote host. Note that this option is written with a capital 'P', because -p is already
reserved for preserving the times and modes of the file in rcp(1).
-p Preserves modification times, access times, and modes from the original file.
Bonus Tip: How can I determine the port being used by the/an SSH daemon to accept SSH connections?
This question can be answered by using the netstat
utility, as follows:
sudo netstat -tnlp | grep sshd
Or, using the far more readable word based netstat option names:
sudo netstat --tcp --numeric-ports --listening --program | grep sshd
The output you will see, assuming your ssh daemon is configured with default values its listening ports, is shown below (with a little trimming of the whitespace in between columns, in order to get the entire table to be visible without having to scroll):
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State ID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 888/sshd: /usr/sbin
tcp6 0 0 :::22 :::* LISTEN 888/sshd: /usr/sbin
Important Note
For the above examples, sudo
was used to run netstat with administrator privs, in order to be able to see all of the Program Names. If you run netstat as a regular user (i.e., without sudo and assuming you don't have admin rights granted to you, via some other method), you will only see program names shown for sockets that have your UID as the owner. The Program Names for sockets belonging to other users will not be shown (i.e., will be hidden and a placeholder hyphen will be displayed, instead):
Proto Recv-Q Send-Q Local Address Foreign Address State ID/Program name
tcp 0 0 127.0.0.1:46371 0.0.0.0:* LISTEN 4489/code
...
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
...
Update and aside to address one of the (heavily upvoted) comments:
With regard to Abdull's comment about scp
option order, what he suggests:
scp -r some_directory -P 80 ...
..., intersperses options and parameters, since the -r
switch takes no additional arguments and some_directory
is treated as the first parameter to the command, making -P
and all subsequent command line arguments look like additional parameters to the command (i.e., hyphen prefixed arguments are no longer considered as switches).
getopt(1)
clearly defines that parameters must come after options (i.e., switches) and not be interspersed with them, willy-nilly:
The parameters getopt is called with can be divided into two parts: options which modify the way getopt will do the parsing (the options and the optstring in the SYNOPSIS), and the parameters which are to be parsed (parameters in the SYNOPSIS). The second part will start at
the first non-option parameter that is not an option argument, or after the first occurrence of '--'. If no '-o' or '--options' option is found in the first part, the first parameter of the second part is used as the short options string.
Since the -r
command line option takes no further arguments, some_directory
is "the first non-option parameter that is not an option argument." Therefore, as clearly spelled out in the getopt(1)
man page, all succeeding command line arguments that follow it (i.e., -P 80 ...
) are assumed to be non-options (and non-option arguments).
So, in effect, this is how getopt(1)
sees the example presented with the end of the options and the beginning of the parameters demarcated by gray text:
scp -r some_directory -P 80 ...
This has nothing to do with scp
behavior and everything to do with how POSIX standard applications parse command line options using the getopt(3)
set of C functions.
For more details with regard to command line ordering and processing, please read the getopt(1)
manpage using:
man 1 getopt
Best Answer
If GlassFish and Oracle Database are installed in the same system, it results in port conflict as both of them use port 8080. Here is the procedure to change port number of GlassFish so that you can run GlassFish at a different port number from Oracle to avoid the port conflict.
Find out the folder where GlassFish is installed*. If you installed GlassFish along with NetBeans, you can find out the folder where GlassFish is installed by using the following procedure.
Select Services window by using Window -> Services in NetBeans IDE
Expand Servers node and select GlassFish Domain
Right click and select Properties option from popup menu
On the right of Domains Folder you can see the folder where GlassFish is installed. For example : C:\netbeans6.8\glassfish-v3\glassfish\domains You can also see the other details regarding Glassfish such as port number, in the same window.
2.Go to the folder where Glassfish in installed.
3.Go into config folder which is as follows (yours might be different): c:\netbeans6.8\glassfish-3\glassfish\domains\domain1\config
4.Open domain.xml using any text editor.
5.Look for 8080 and change it to some other port number that doesn’t conflict with other port numbers. I generally change it to 9999.
6.Save domain.xml. 7.Now you need to remove GlassFish from NetBeans and add it again so that NetBeans IDE understands the new port number. For this do the following:
8.Restart GlassFish, if it was already running.