Can't open files outside of the workspace folder properly

#1

Cloud9 is for developers, and development frequently requires us to update things outside of the workspace, so why can’t we do that properly?

For example, if I want to install rethinkdb, I need to edit the conf file which is located several folders into /etc.

I can only get there through the terminal, and I can only edit the file with something like nano. That would be just fine (although a silly limitation) except that scrolling through a text file in the terminal on cloud9 is broken and doesn’t scroll properly most of the time. It seems like an intermittent issue, but a very frequent one that makes it incredibly frustrating to use.

The c9 command was implemented to allow us to open a file in the full IDE from the command line. Perfect! Wait, it can only open files I can already see in the workspace file tree. Anything outside of that just hangs forever, essentially making that command useless.

Here would be the most obvious fixes to make this a whole hell of a lot more enjoyable to use (or just plain usable):

  1. Let us access the whole file system with the file tree navigation UI. It’s not like it’s protected anyways if I can get to it with the terminal - and it would make cloud9 entirely useless if we couldn’t get to it at all.

  2. Fix the c9 command to work on all files, even outside the workspace.

  3. Fix scrolling through text files in the terminal. This one is only necessary if we can’t fix 1 or 2, but it seems like a straight forward refresh bug.

#2

I would also request that 3 is fixed regardless. Sometimes it’s just quicker to use nano rather than navigate through a deep directory structure.

#3

This is mostly due to the old version of cloud9, where there was no terminal, and sandboxing was useful.
I agree that it should be changed.
but until it is one can use the following shell script as a workaround

edit() {
    local FILE=$(cd "$(dirname "$1")"; pwd)/$(basename "$1")
    local name=${FILE//\//}
    
    if [ ! -e "$FILE" ]; then
        echo "creating $FILE"
        touch "$FILE" || sudo touch "$FILE" > /dev/null
    elif [ -f "$FILE" ]; then
        :
    elif [ -h "$FILE" ]; then
        FILE=$(readlink "$FILE")
    else
        echo "can't edit $FILE"
        exit -1
    fi
    local TMP_DIR=~/.c9/edit-tmp
    mkdir -p "$TMP_DIR"
    [ -z "$FILE" ] && cp "$FILE" "$TMP_DIR/$name"
    c9 open --wait "$TMP_DIR/$name" 
    if [ -e "$TMP_DIR/$name" ]; then
        cat "$TMP_DIR/$name" | sudo tee "$FILE" > /dev/null
        rm "$TMP_DIR/name"
        ls -ladh "$FILE"
    fi
}

Could you please describe 3 in a bit more detail, in which cases scrollback doesn’t work in cloud9 terminal and works in others? AFAIK nano and vim disable terminal scrollback on all terminal emulators.

Show root folder in file tree
#4

@harutyun…
Well, here’s an example of the issue I have … as @cpath mentioned, it seems to be to do with refreshing or redrawing?

It’s not the best example but it gives you an idea. As you will see, when I scroll down/up the entire file doesn’t get redrawn.
Over time, this gets worse and becomes impossible to read.

nano.gif534×794 514 KB

Edit:
Possibly this illustrates it better … everything becomes impossible to read (Here is an example to the actual file if you want to see how it’s structured in terms of readability)

nano-drupal-settings.gif666×794 896 KB

#5

That’s exactly what I’m talking about. I suspect it’s a refresh/draw issue especially because triggering a browser resize window event redraws it correctly.

#6

Thanks for the script, I’ll give that a go!

As for the file tree being accessible, does that have anything to do with why cloning a workspace doesn’t clone everything, like apt-get packages or things installed outside of the workspace folder?

Being able to clone the entire environment, along with fixing the other issues I mentioned would make c9 pretty close to perfect for our team. Right now we can clone a “starter” workspace but we still have to install and configure a number of things that don’t get cloned over because they’re somewhere else in the file system.

imlaurie’s reply above shows exactly the problem. It’s to do with cursor scrolling in the terminal, like holding the down arrow when nano is opened.

#7

Turns out scrolling issue is caused by running nano inside tmux when TERM is set to xterm-256color

After setting export TERM=screen nano seems to work well but that breaks ctrl-arrow movement in vim

Nano editor in bash - display problem
#8

Thanks for finding that out! I’ll set that up since I prefer nano over vim.

#9

Great, thanks @harutyun … I also don’t use vim so I’m more than happy with that.

#10

Being able to clone the entire environment,

cloning already should clone the entire environment, i am told that it uses same mechanism as archiving, so it can’t miss any of the files. Could you please tell a bit more about the issue you are seeing.

#11

Hi there, sorry I must have missed the notification about this reply.

I’ve found that some things don’t transfer over in a clone, or at least they didn’t earlier this year, haven’t tried for a month or two. I remember expecting that it would be like cloning a digital ocean droplet, like an image clone, but it missed a few things.

I can’t remember anything specific at the moment, but from what I recall it was things like apt-get installs or things stored in /etc. I think maybe postgres database users and config may also not have been transferred but I could be wrong on that. I’ll try a few clones today and write down anything that doesn’t carry over.

#12

I saw another report that run configurations don’t carry over to the cloned workspace. @cpath if you could confirm this that would be helpful :thumbsup:

#13

Hi , I did not understand how to access the root folders in order to modify the files with the c9 editor.

Could you explain clearly how to set up?

Thanks

#14

Can you explain how I might implement this in detail? I’m on an Amazon Linux ec2 - using Cloud9 to ssh in and want to be able to edit files in /var/www