Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blank terminal #32

Closed
alegag opened this issue Feb 24, 2017 · 6 comments
Closed

Blank terminal #32

alegag opened this issue Feb 24, 2017 · 6 comments

Comments

@alegag
Copy link

alegag commented Feb 24, 2017

Atom: 1.14.3 (had same issue in 1.13.x)
Termination: 0.4.0
OS: Fedora Workstation 25

I install the package, change nothing in settings (Shell Override is set to "/usr/bin/bash", which exists on my system).

I get a terminal with no prompt. What ever I try, I never get the prompt.

screenshot from 2017-02-24 09-50-15

@Fred-Barclay
Copy link
Collaborator

Fred-Barclay commented Feb 24, 2017

Hi @alegag
What happens if you set the shell override to /bin/bash?

Also, can you give me this output from your system?

$ which bash
$ whereis bash

I'm downloading Fedora now so I can try to replicate this (bash is only in /bin/bash for my Debian system).

Cheers!
Fred

EDIT: one more thing to try is to simply type bash in the shell override field instead of using the full path to bash.

@alegag
Copy link
Author

alegag commented Feb 24, 2017

Hi @Fred-Barclay

First, thanks for the quick reply !

I've tried both /bin/bash and bash as the Override value, restarted Atom in between each test to make sure, same result.

# which bash
/usr/bin/bash
# whereis bash
bash: /usr/bin/bash /usr/share/man/man1/bash.1.gz /usr/share/info/bash.info.gz

Let me know if I can be of any more assistance !
Thanks !

@Fred-Barclay
Copy link
Collaborator

Fred-Barclay commented Feb 25, 2017

Sure mate, no worries. 😄
This is odd. I can't replicate it with Fedora Workstation 25 64-bit (Xfce spin and fully updated), and /bin/bash is the default shell in the Override field:
term1

Can we try with a new Atom profile? Maybe something's gone bad in it.

mv ~/.atom ~/.atom_old
apm install termination

Then launch Atom. Any change?

EDIT: Please also launch the Developer Tools (Views >> Developer >> Toggle Developer Tools or Ctrl+Shift+I) and type in the following:

process.platform
process.env.SHELL

What does it say?

@alegag
Copy link
Author

alegag commented Feb 25, 2017

Your test put me on the right track to find the bug. I don't know if this is on your side or on Atom's side tho'.

In my setup, my ".atom" directory is on an NFS share, so I can use the same Atom settings on multiple computers. That share is mounted "noexec" by default. That's what prevent the terminal from showing.

To reproduce, supposing you have a "/home" on a dedicated partition on your Linux box, close Atom and run this:

sudo mount -o remount,noexec /home

Then open Atom, the terminal will not execute anymore.

To revert:

sudo mount -o remount,exec /home

I don't know how the plugin works, but if a "program" is called, you might want to prefix it by the interpreter (like calling /usr/bin/python ${atom}/packages/termination/plugin.py). Maybe you can detect the OS and make a test to see if the script is executable ? Maybe this is all handled by Atom and you have no control over this.

Would be nice if it could be backed in the plugin, would avoid to set executable an partition I don't want to set executable in the first place ;-)

@Fred-Barclay
Copy link
Collaborator

Hi,
I will have to do some thinking on this. It may or may not be something that I can control, or would want to control from Termination.

Is .atom in your /home? If not, could you link/copy/do something so that the "real" .atom stays on the noexec partition but you can still interact with a clone of sorts? (Not sure if that makes sense.)

Cheers!
Fred

@alegag
Copy link
Author

alegag commented Feb 27, 2017

Hi @Fred-Barclay

No sure to follow ;-)

The way I was setup was that the ~/.atom was a symlink to ~/Development/.atom

The ~/Development partition was set noexec.

By result, ~/.atom content was noexec.

I've tried to "bind mount" with "exec" flag, but it did not worked.

What I did to workaround this issue is to add an extra entry in my fstab where I do something similar to:

Server:/home/user/Development/.atom	/home/user/.atom	nfs	defaults,exec	0 0

That way, ~/.atom is now "executable", so terminal works.

This case could also just be documented in the README, that could be enough for the next person that comes around with that problem (I've seen in the past the same problem with other Terminal packages (the one you cloned from, and the one it was cloned from, among others), but none ever proposed a fixe or even a workaround).

Of course, if you can control that on your side, that would be a better solution, but otherwise, documentation seems to be a good fit too !

Let me know if I can be of any assistance !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants