Add Command Prompt Here Shortcut to Windows Explorer

How can I add a Command Prompt option to the default Explorer right click context menu?

If you find that you frequently open a Command Prompt window and change to a specific directory, you can add the Command Prompt to your shortcut menu. This option enables you to right-click on a folder within Windows Explorer and choose the Command Prompt - which opens a Command Prompt window with that folder as your active directory.

To add the Command Prompt option to the default right click context menu in Windows Explorer you can do one of the following:

Note: For Windows Vista this feature is already built in the operating system. Read Quickly Open Command Prompt Here in Windows Vista for more info.

Method #1: Microsoft Powertoys

This is the easiest and most idiot-proof method.

Use the old Microsoft Powertoy called "DOSHERE". You can download it from HERE (1kb). Unzip it and then right click the INF file and choose install.

You can also use the newer MS Powertoys found HERE. Download the Open Command Window Here file and install it.

Method #2: Send to Toys

One of my favorite tools, one that I usually install right after finishing setting up any new system.

Send To Toys is an enhancement of the Send To system menu. It has many nice features including:

• Send To Toys Control Panel Applet allows you to manage the Send To system menu content, and configure Send To Toys settings.
• "Add to Send To menu" and "Remove from Send To menu" allows you to personalize the Send To system menu for drives, folders, and programs.
• Send To "Clipboard (as name)" copies the name of the file or files to the clipboard. Hold down the CTRL key to change the settings for this extension.
• Send To "Command Prompt" opens a DOS console window, setting the current directory to the selected folder. If the selection was a file, the folder containing the file will be the active directory and the name of the file will be typed for you at the prompt. Hold down the CTRL key to change the active directory to a different folder
• Send To "Favorites" adds a shortcut to your Favorites list. Hold down the CTRL key for the "Add Favorite" dialog.
• Send To "Folder..." sends a file or files to another folder, you will be shown a dialog box that lets you choose where the files should be copied. To move the files press and hold down the SHIFT key. The creation of a new folder is not supported on Windows 95, 98, and NT.
• Send To "Recycle Bin" send a file or files to the Recycle Bin. Hold down the CTRL key to perform a file shredding.
• Send To "Run..." sends a file or files to the Run command dialog

Send to Toys is freeware and can be installed on any version of Windows.

Download Send to Toys v2.4 (527kb)

Method #3: Manually add the context menu

1. In explorer, open Tools, Folder Options.
2. Select the File Types tab.
3. For Windows XP: Go to NONE / Folder.
4. For Windows 2000: Press n to scroll to the N/A section.
5. For Windows NT/98/95: Press f to scroll to the Folders section.
6. Select the entry labeled Folder
7. For Windows 2000/XP: Press Advanced button.
8. For Windows NT/98/95: Press Edit button.
9. Select New
10. In the action block type "Command Prompt" without the quotes.
11. In the app block type "cmd.exe" without the quotes.
12. Save and exit Folder Options.

Now right click on Start, you should have a new drop down option. Open explorer and right click on a folder, select Command Prompt and a command window opens in that folder.

Read this thread for some information on how to remove the context menu:

Command Prompt Quickie - Petri.co.il forums by Daniel Petri

Method #4: Through batch file

1. Begin by creating a batch file. For example, you could create a batch file named StartPrompt.cmd. Add the following commands to your batch file:

@echo off
cd /d %1
Title %~f1

1. Save this batch file to your Windows NT/2000/XP root directory (which is usually C:\WINNT or C:\WINDOWS for XP).
2. Open Windows Explorer.
3. Choose View | Options to display the Options dialog box.
4. Select the File Types tab.
5. In the list of Registered File Types, select Folder then click Edit.
6. Click New to display the New Action dialog box.
7. In the Action text box, type Command Prompt.
8. In the Application Used To Perform Action text box, type:

cmd.exe /a /k c:\winnt\StartPrompt "%l"

1. Click OK to close the New Action dialog box, then click Close twice.

Open Windows NT Explorer, then right-click on a folder. You should now see a new option called "Command Prompt" on the shortcut menu. If you choose this option, Windows Explorer opens a new Command Prompt window with the selected directory as your current directory.

Method #5: Through the Registry

1. Navigate in your Registry to

   HKEY_LOCAL_MACHINE/Software/Classes/Folder/Shell

   and create a key called "Command Prompt" without the quotes.

2. Set the default string to whatever text you want to appear in the right-click menu.
3. Create a new key within your newly created command prompt named "command," and set the default string to

   cmd.exe /k pushd %1

   You may need to add %SystemRoot%\system32\ before the cmd.exe if the executable can't be found.

4. The changes should take place immediately. Right click a folder and your new menu item should appear.

Note: You can do the same for Windows 98. Type in "c:\windows\command.com /k pushd %1" (without the quotes).

If you want ClearType over RDP with XP SP3 (sorry, only SP3+), add the following registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations]
"AllowFontAntiAlias"=dword:00000001

and 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

“AllowFontAntiAlias”=dword:00000001

After you add that registry key, simply reboot the server (XP), and reconnect. From what I can tell, the client options no longer matter. Even if I uncheck the “Font Smoothing” option, it still uses ClearType. It’s not a big deal, but I thought it was worth mentioning.

原文链接：http://www.securityfocus.com/infocus/1816

Introduction

Whenever we SSH from one machine to another, we establish a secure encrypted session. This first article in this SSH series[1] looked at properly verifying a server's host key, so that we can be sure that no attacker is able to perform a man-in-the-middle attack and gain access to read or manipulate what we do in that session. Other articles in this series looked at removing the need for static passwords using SSH user identities[2], and then using ssh-agent[3] to automate the task of typing passphrases.

SSH also has a wonderful feature called SSH Port Forwarding, sometimes called SSH Tunneling, which allows you to establish a secure SSH session and then tunnel arbitrary TCP connections through it. Tunnels can be created at any time, with almost no effort and no programming, which makes them very appealing. In this article we look at SSH Port Forwarding in detail, as it is a very useful but often misunderstood technology. SSH Port Forwarding can be used for secure communications in a myriad of different ways. Let's start with an example.

LocalForward Example

Normally, your mail client will establish a TCP connection to the mail server on port 110, supply your username and password, and download your email. You can try this yourself using telnet or nc on the command line:

  xahria@desktop$ nc mailserver 110
  +OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready.
  USER xahria
  +OK
  PASS twinnies
  +OK User successfully logged on.
  LIST
  +OK 48 1420253
  1 1689
  2 1359
  3 59905
  ...
  47 3476
  48 3925
  .
  QUIT
  +OK SuperDuper POP3 mail server signing off.
  
  xahria@desktop$

We can wrap this TCP connection inside an SSH session using SSH Port Forwarding. If you have SSH access to the machine that offers your service (POP, port 110 in this case) then SSH to it. If you don't, you can SSH to a server on the same network if the network is trusted. (See the security implications of port forwarding later in this article.)

In this case, let's assume we don't have SSH access to the mail server, but we can log into a shell server on the same network, and create a tunnel for our cleartext POP connection:

  # first, show that nothing's listening on our local machine on port 9999:
  xahria@desktop$ nc localhost 9999
  Connection refused.
  
  xahria@desktop$ ssh -L 9999:mailserver:110 shellserver 
  xahria@shellserver's password: ********
  
  xahria@shellserver$ hostname
  shellserver

From a different window on your desktop machine, connect to your local machine (localhost) on port 9999:

  xahria@desktop$ nc localhost 9999
  +OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready.
  USER xahria
  +OK
  PASS twinnies
  ...

Before we connected to the shellserver with SSH, nothing was listening on port 9999 on our desktop - once we'd logged in to the mail server with our tunnel, this port was bound by our SSH process, and the TCP connection to local port 9999 was magically tunneled through SSH to the other side.

Let's describe how this works in detail, using the example above.

• You launch the /usr/bin/ssh SSH client on the command line.
• The SSH client logs into the remote machine using whatever authentication method (password, Pubkey, etc) is available.
• The SSH client binds the local port you specified, port 9999, on the loopback interface, 127.0.0.1.
• You can do anything in your remote machine that you want -- tar up some files, write to some users, delete /etc/shadow... This interactive login is completely usable, or you can just let it hang around doing nothing.
• When a process connects to 127.0.0.1 on port 9999 on the client machine, the /usr/bin/ssh client program accepts the conection.
• The SSH client informs the server, over the encrypted channel, to create a connection to the destination, in this case mailserver port 110.
• The client takes any bits sent to this port (9999), sends them to the server inside the encrypted SSH session, who decrypts them and then sends them in the clear to the destination, port 110 of the mailserver.
• The server takes any bits received from the destination, mailserver's port 110, and sends them inside the SSH session back to the client, who decrypts and sends them in the clear to the process that connected to the client's bound port, port 9999.
• When the connection is closed by either endpoint, it is torn down inside the SSH session as well.

SSH Port Forward Debugging

  xahria@desktop$ ssh -v -L 9999:mailserver:110 shellserver 
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Rhosts Authentication disabled, originating port will not be trusted.
  debug1: Connecting to shellserver [296.62.257.251] port 22.
  debug1: Connection established.
  debug1: identity file /home/bri/.ssh/identity type 0
  debug1: identity file /home/bri/.ssh/id_rsa type 1
  debug1: identity file /home/bri/.ssh/id_dsa type 2
  ...
  debug1: Next authentication method: password
  xahria@shellserver's password: ********
  debug1: Authentication succeeded (password).
  debug1: Connections to local port 9999 forwarded to remote address localhost:110
  debug1: Local forwarding listening on 127.0.0.1 port 9999.
  debug1: channel 0: new [client-session]
  debug1: Entering interactive session.
  debug1: channel 0: request pty-req
  debug1: channel 0: request shell
  xahria@shellserver$

As you can see, there's a brief mention of port 9999 being bound and available for tunneling. We haven't made a connection to this port yet, so no tunnel is active yet. You can use the ~# escape sequence to see the connections in use. This sequence only works after a carriage return, so hit enter a few times before trying it:

  xahria@shellserver$ (enter)
  xahria@shellserver$ (enter)
  xahria@shellserver$ (enter)
  xahria@shellserver$ ~#
  The following connections are open:
    #1 client-session (t4 r0 i0/0 o0/0 fd 5/6)
  xahria@shellserver$

You can see that there's only one connection, our actual SSH session from which we're typing those unix commands.

Now, in a different window if we do a telnet localhost 9999, we'll open up a new connection through the tunnel, and we can see it from our SSH session using ~#

  xahria@shellserver$ (enter)
  xahria@shellserver$ ~#
  The following connections are open:
    #1 client-session (t4 r0 i0/0 o0/0 fd 5/6)
    #2 direct-tcpip: listening port 9999 for mailserver port 110,
                     connect from 127.0.0.1 port 42789 (t4 r1 i0/0
                     o0/0 fd 8/8)

You can see that now we have both the SSH session we're using, plus a tunnel, the second entry. It tells you all you need to know about the connection -- it came from our local machine (127.0.0.1) source port 42789, which we could look up with netstat or lsof output if we were curious about it.

RemoteForward Example

The classic example of using a Remote Forward goes something like this. You're at work, and the VPN access is going to be down for maintenance for the weekend. However you really have some important work to do, but you'd rather work from the comfort of your desk at home, rather than being stuck at work all weekend. There's no way for you to SSH to your work desktop because it's behind the firewall.

Before you leave for the evening, you SSH from your work desktop back to your home network. Your ~/.ssh/config file has the following snippet:

  lainee@work$ tail ~/.ssh/config
    Host home-with-tunnel
       Hostname      204.225.288.29
       RemoteForward 2222:localhost:22
       User          laineeboo
  
  
  
  lainee@work$ ssh home-with-tunnel
  laineeboo@204.225.228.29's password: ********
  
  laineeboo@home$ ping -i 5 127.0.0.1
  PING 127.0.0.1 (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms
  64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.2 ms
  ...

We've set up a tunnel using the RemoteForward option in the SSH configuration file. (We could have set it up on the command line using the -R option if we'd prefered.) Just to make sure our firewall doesn't kill the connection for inactivity, we run a ping for grins. Then we head on home.

Later that evening, we can sit down on our home machine and see that we're logged in:

  laineeboo@home$ last -1
  laineeboo  pts/18   firewall.my_work.com Tue Nov 23 22:28   still logged in
  
  laineeboo@home$ ps -t pts/18
   PID TTY          TIME CMD
  3794 pts/18   00:00:00 ksh
  4027 pts/18   00:00:00 ping -i 5 127.0.0.1

Now comes the payoff - our tunnel is listening on our home machine on port 2222, and will be tunneled back through the corporate firewall to our work machine's port 22. So to SSH to work from home, since we have our tunnel ready, we simply point /usr/bin/ssh to port 2222:

  laineboo@home$ ssh -p 2222 lainee@localhost 
  lainee@localhost's password: ********
  
  lainee@work$

Success!

Port Forwarding Cheat Sheet

LocalForwards

Command Line Option	-L local_listen_port:destination_host:destination_port
Configuration file entry	LocalForward local_listen_port:destination_host:destination_port
local_listen_port is on	SSH client loopback interface
destination_host is contacted from	SSH server host

RemoteForwards

Command Line Option	-R remote_listen_port:destination_host:destination_port
Configuration file entry	RemoteForward remote_listen_port:destination_host:destination_port
remote_listen_port is on	SSH server loopback interface
destination_host is contacted from	SSH client host

Forwards can be confusing - we typically think of connections as being made up of four things - the local IP and port, and the remote IP and port. In the forward definition you create, you only have three things because the first port is always either the SSH client or server machine, and thus isn't specified.

Port Forward Security

In general, you don't want to allow other machines to contact your SSH tunnel so this is the correct setting. If you want to allow these ports to be available to any machine, then use one of the following:

The other important thing you must remember is that the data connection is only encrypted inside the SSH connection. If your destination_host you specify is not localhost[6] then the portion of the connection that extends out of the tunnel is not encrypted. For example if you used the the following:

  desktop$ ssh -L 8080:www.example.com:80 somemachine

then any connection to localhost:8080 will be encrypted from your desktop through to somemachine, but it will be in cleartext from somemachine to www.example.com. If that fits your security model, no problem. But keep it in mind.

We'll see how you can put further limits on port forwards in a future article, such as rejecting or limiting them based on the SSH Pubkeys/Identity that is used for authentication.

DevilsPie：

A window-matching utility, inspired by Sawfish's “Matched Windows” option and the lack of the functionality in Metacity. Metacity lacking window matching is not a bad thing — Metacity is a lean window manager, and window matching does not have to be a window manager task.

Devil's Pie can be configured to detect windows as they are created, and match the window to a set of rules. If the window matches the rules, it can perform a series of actions on that window. For example, I can make all windows created by X-Chat appear on all workspaces, and the main Gkrellm1 window does not appear in the pager or task list.

这个工具还是很强大，，可以自定义很多程序启动时的属性，如是否最大化，在哪个桌面等等。。
使用指南可详见：http://www.burtonini.com/blog/computers/devilspie

比如让mplayer自动always On Top:
(if
    (matches (application_name) "^MPlayer")
    (begin
        (stick)
        (above)
    )
)
让QTerm到窗口3：
(if
    (matches (application_name) "^QTerm")
    (begin
        (set_viewport 3)
        (maximize)
    )
)

Strange error in Debian 4.0: “error executing gpgv”