If I launch Cygwin using the Start Menu shortcut it created, I have access to ping and inetutils. However, if I launch Cygwin directly from C:\Cygwin64\Bin\mintty.exe then there's no ping to be had; not the "socket operation not permitted message" you'd get from a non-admin launch, I get the one you'd receive if ping wasn't installed at all.
Am I overlooking something? The only switch in the shortcut is "-i /Cygwin-Terminal.ico", and manually adding that to a shortcut I create myself doesn't rectify the situation. This is occurring on Windows 8.1 Pro in an admin account.
Running mintty without arguments will run your $SHELL but not as login shell, which won't set PATH etc.
From mintty documentation synopsis and invocation:
mintty [OPTION]... [ - | PROGRAM [ARG]... ] [...]
If a program name
is supplied on the command line, this is executed with any additional
arguments given. Otherwise, mintty looks for a shell to execute in the
SHELL environment variable. If that is not set, it reads the user’s
default shell setting from /etc/passwd. As a last resort, it falls
back to /bin/sh. If a single dash is specified instead of a program
name, the shell is invoked as a login shell.
So, the following should get you going, it worked for me.
c:\cygwin64\bin\mintty -
That is, invoke mintty with - as parameter
Related
I've found a very strange issue, when in linux terminal I type "enable -n trap", it would disable the trap linux builtin command. But if I put it into a script like
#!/bin/bash
enable -n trap
and then run the script, there's no error but the command is also not disabled. Really appreciate if someone could share what is happening and how to run it in some file instead of directly in the terminal. Thank you!
The enable command only affects the current shell. When you run a script, that script is executed in a new process, so:
A new shell starts
The enable command runs and disables the trap command in that shell
The shell exits
If you want to affect the current shell, your only option is to source the script using the . (or source) command. If the script is named disable-trap.sh and is in your $PATH, you can run:
. disable-trap.sh
You can also provide a full path to the script:
. /path/to/disable-trap.sh
Sourcing a script like this is largely equivalent to typing the same commands in at the command line: it executes the instructions in the script in the current shell, rather than spawning a new process.
The problem first:
The subshell of mc has a different prompt compared to the parent shell and my tcsh environment. All the other settings/variables/aliases are available in mc's subshell, only the prompt is not "passed" correctly it seems. I have no idea why that happens.
Man page says:
An extra added feature of using the subshell is that the prompt displayed by the Midnight Commander is the same prompt that you are currently using in your shell.
Background:
I am using mc.4.8.23 which I have installed on my own locally (because no root permission). Did basically those two steps:
./configure --prefix=<absolute path>/eda_tools/mc/mc-4.8.23/install --bindir=<absolute path>/eda_tools/mc/mc-4.8.23/bin --with-screen=ncurses
make install
Rest of mc works fine.
What I have tried so far:
putting a test prompt and a test alias into tcshrc within ~/.config/mc & ~/.mc & ~/.local/share/mc. None of those locations seem to be evaluated at mc startup. I can neither see a changed prompt, nor the test alias.
Have temporarily changed the prompt within .cshrc to a very simple one. Did not help.
changing the prompt on-the-fly within the mc's subshell does temporarily work. So it seems, that the prompt string itself is OK and understood.
Does someone has an idea?
Try to put your tcshrc with prompt settings in ~/.local/share/mc/ directory.
I can't verify with tcsh, but this location definitely works (with bashrc) for bash subshell in mc.
The prompt for tcsh is hard coded in the source file src/subshell/common.c in function init_subshell_precmd. To keep your prompt recompile mc with this patch applied:
--- src/subshell/common.c.org 2019-06-16 19:49:31.041841616 +0200
+++ src/subshell/common.c 2020-01-12 14:17:03.928956667 +0100
## -886,7 +886,6 ##
case SHELL_TCSH:
g_snprintf (precmd, buff_size,
"set echo_style=both; "
- "set prompt='%%n#%%m:%%~%%# '; "
"alias precmd 'echo $cwd:q >>%s; kill -STOP $$'\n", tcsh_fi
break;
This question already has answers here:
How to open a new tab in GNOME Terminal from command line? [closed]
(10 answers)
Closed 3 years ago.
I actually want to run some commands of the same script on different tabs or terminal because these commands are activating servers and listening to different ports. So they have to be always active. As well, I want to have a reference to the tab or the terminal so that I can later shut them down at the end of the script. Help please.
I tried a simple script test to see if I could find a way for opening other tabs :
tab=" --tab"
options=()
cmds[1]="echo Banana"
cmds[2]="echo Cat"
for i in 1 2; do
options+=($tab -e "bash -c \"${cmds[i]} ; bash\"" )
done
gnome-terminal "${options[#]}"
exit 0
but I get this as a result :
./test.sh
# Option “-e” is deprecated and might be removed in a later version of gnome-terminal.
# Use “-- ” to terminate the options and put the command line to execute after it.
# Option “-e” is deprecated and might be removed in a later version of gnome-terminal.
# Use “-- ” to terminate the options and put the command line to execute after it.
Is there any way to open tabs ? and get a reference to each one so that I can shut down commands related to servers once the treatment is done ?
You could use a programm called tmux. It's a terminal-multiplexer, like screen. With that you can open different sessions and windows (these are like tabs) in the same terminal window. They can be referenced by name or id via script.
It's very probable, that the package manager of your Linux distribution has tmux.
P.S: I have to post an answer instead of a comment as I don't have enough reputation for commenting.
This is what I found for man gnome-terminal ; I think that could help , thanks
gnome-terminal(1) General Commands Manual gnome-terminal(1)
NAME
gnome-terminal — is a terminal emulation application.
SYNOPSIS
gnome-terminal [-e, --command=STRING] [-x, --execute ] [--window-
with-profile=PROFILENAME] [--tab-with-profile=PROFILENAME] [--window-
with-profile-internal-id=PROFILEID] [--tab-with-profile-internal-
id=PROFILEID] [--role=ROLE] [--show-menubar] [--hide-menubar]
[--geometry=GEOMETRY] [--working-directory=DIRNAME] [-?, --help]
DESCRIPTION
GNOME Terminal is a terminal emulation application that you can use to
perform the following actions:
Access a UNIX shell in the GNOME environment.
A shell is a program that interprets and executes the commands that you
type at a command line prompt. When you start GNOME Terminal, the
application starts the default shell that is specified in your system
account. You can switch to a different shell at any time.
OPTIONS
-e, --command=STRING
Execute the argument to this option inside the terminal.
-x, --execute
Execute the remainder of the command line inside the termi‐
nal.
--window-with-profile=PROFILENAME
Open a new window containing a tab with the given profile.
More than one of these options can be provided.
--tab-with-profile=PROFILENAME
Open a tab in the window with the given profile. More than
one of these options can be provided, to open several tabs .
--window-with-profile-internal-id=PROFILEID
Open a new window containing a tab with the given profile ID.
Used internally to save sessions.
I'll be glad if someone can fix the title to be more appropriate since I'm pretty new to terminal.
I have an issue with terminal. Once I execute a command, if it goes to the next line, I can't close it or revert it. I assume it starts the executable or asks for more parameters using >
For example:
//Windows Machine
vagrant up
//Vagrant Instance Unix Machine
$ git
>
>
>
> ... it goes on like this, I can't close > so I can't execute other commands
The only solution on fixing is restarting the terminal (which means I need to restart Vagrant instance)
It happens on some commands only - not all, so I don't know what makes a difference.
For example, executing composer, I get information about Composer and terminal goes back to main state. However, if I execute things like php, git, mysql, > symbol appears and I can't return from there.
So, two basic questions;
What causes this?
How can I terminate the current command to go back main state?
Any help would be greatly appreciated.
Ps. I use both windows terminal and unix terminal and this issue happens on both.
Normally you'll see a > prompt if you've entered a command that's syntactically incomplete, for example if there's a unterminated string literal:
$ echo 'hello
> '
hello
$
It means that the shell is waiting for you to type the rest of the command, or at least enough of it to make for something that's not a syntax error.
In this example, the default prompt, $PS1, is '$ ', and the secondary prompt, $PS2, is '> '. Read the documentation for your shell (probably bash) for more information.
You can cancel the current command and get back to your primary prompt for a new command by typing Control-C.
This is all about the behavior of your shell; it has nothing to do with your terminal (almost certainly a terminal emulator), which merely provides a GUI for your shell to run in.
I am installing a virtualenv and want to understand what's going on.
$ curl -O https://raw.github.com/pypa/virtualenv/master/virtualenv.py
- I understand curl fine
$ python virtualenv.py my_new_env
- Understand this, too
$ . my_new_env/bin/activate
- Here's where I get lost. What is the period doing here?
(my_new_env)$ pip install ...
- What does it mean to have the parentheses here? Does this use tell me I'm in a folder?
The dot is a command that means to read and execute the contents of the given script in the current shell (normally running a shell script runs it in a new process.) Evaluating the script in the current shell can change the environment variables of the current shell, so the behavior of subsequent commands is affected.
I don't know for sure about the parentheses, but I don't think they're meant to be syntax you type. As they come before the '$' prompt, perhaps that's literally what you'll get as your new prompt after running the activate script, to show you that your environment has been changed?
The dot is essentially an "execute" command — execute the commands in my_new_env/bin/activate as though they were typed into your prompt, essentially.
The parentheses shown in the prompt (at least in the tutorial instructions) then indicate that you're typing commands in your new virtual environment, and not in your original (real) environment.