what's the best way to transfer a file (using the bash command-line) from one server directly to mine?

files on other server here:

http://www.movabletype.org/downloads/stable/

i think there are 2 separate prgms that will do this for me, but i can't recall what they are.

this will save me from having to download the file to my hard drive & then upping it to the site.

i have absoluteb path available for my server .. to the exact folder into which I wanna stick it.

Just cd to the directory on you server where you want the files and then use wget to download them from moveabletype.

wget, then a space, then the remote directory, then what?

(after i cd to the destination directory)

what is the other command? that will do the same thing.

what if the remote directory is password protected? (it's not.)

Rad wrote on Dec 12^th, 2010 at 4:35pm:

wget, then a space, then the remote directory, then what?

The second argument is where you want to file to download to and the file name you want it to have.  Since the default is the working directory, I usually just put "./" (without the quotes) meaning "current working path."


Rad wrote on Dec 12^th, 2010 at 4:35pm:

what is the other command? that will do the same thing.

Not sure what you are asking.  wget is the best way to download on the command line using the http protocol.  You could also use a text based browser if you have one installed.  Try "lynx http://moveabletype.org"

The other popular way to transfer files between hosts is scp, but it requires ssh access to both machines.


Rad wrote on Dec 12^th, 2010 at 4:35pm:

what if the remote directory is password protected? (it's not.)

man wget
      --user=user
      --password=password

Don't forget about the man pages.

what about curl

http://daniel.haxx.se/docs/curl-vs-wget.html

MrMagoo wrote on Dec 12^th, 2010 at 10:58pm:

usually just put "./" (without the quotes) meaning "current working path."

why not just a period without the slash, since a period means 'current directory', no?

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1247608529

test from ubuntu virtual machine.

Rad wrote on Dec 12^th, 2010 at 11:27pm:

what about curl

Sure, you could get curl to do what you want.


Rad wrote on Dec 12^th, 2010 at 11:32pm:

why not just a period without the slash, since a period means 'current directory', no?

Say the file is named file.tgz.  You want the end file name to be "/current/directory/file.tgz"  If you're in /current/directory, then . = /current/directory  If you just use ., then you are asking the system to name the file /current/directoryfile.tgz, which will cause an error.  ./ will get you what you want.  Try both and see.

happy to report wget worked just like you said it would.

the installer package never touched my local hard drve. i love the shell.

but .. do you know a way i could change the default directory/file perms? .. during the unzipping?

i'm talking about the modx cms:

http://rtfm.modx.com/display/revolution20/Basic+Installation

they have only a zip .. no tarball, far as i can tell.

since i use suPHP as my default PHP handler, 755 is the desired perm on directories.

but the install (or my server?) .. is setting them all the 775.

the files all decompress (unzip- a filename.zip) with 664.

ths guy says he thinks suPHP likes 644 for files & 755 for directories.

http://modxcms.com/forums/index.php/topic,59059.msg336317.html

do i not need some 'execute' perms in there, somewhere?

happy holidays.

ps - my tech sppt guy at wiredtree says suPHP expects 755 for directories & 655 for files.

755 sounds right for directories but never heard of 655 before for files.

he knows of no way to tweak perms on unzipping.

You could easily make everything 755 by using chmod.  From the top directory of your modx cms, just run: chmod 755 -R *

"*" is the wildcard meaning 'everything'.  -R is recursive, which means if it hits a subdirectory, it will also run the same command on that subdirectory.

If you need to be picky about files vs directories, its a little trickier.  You could use find.  From the parent directory, run:

find ./ -type d -e chmod 755
find ./ -type f -e chmod 644

The first one finds everything in the current path or below with a file type of 'directory' (-type d.)  For each match, it executes (-e) the chmod command.  The second one is the same except it looks for files with a type "regular file", which will match all your php files, text files, and everything like that.  Make sure you cd to the parent directory of modx before you run this command.  Running it from the root directory will cause you a *huge* headache.

I don't know of any way to tweak the permissions during unzip, but the command above will let you quickly and easily set it.  I would try 644 first for the files.  If it turns out you need 655, you can easily change it.  You always want to be as restrictive as you can for security reasons.


Rad wrote on Dec 26^th, 2010 at 5:20pm:

do i not need some 'execute' perms in there, somewhere?

Maybe not.  What you are executing is the PHP interpreter.  The interpreter takes a text file (your php files) as input.  So as long as the php interpreter has read permission on the php files, it might be ok. 

I can certainly dream up a situation where you would need to give execute permission on the files, but it isn't always necessary.

beautiful.


MrMagoo wrote on Dec 26^th, 2010 at 10:03pm:

find ./ -type d -e chmod 755 find ./ -type f -e chmod 644

the modx installer has an option to set NEW folder & file perms (which is cool). The default for this opton is 755 & 644.

Here, I'll drop in a screen shot for you.

http://gfx03.radified.com/gfx1/modx_CMS_install_options.png

Bottom line is that I waited until version 06 before attempting an install. I'm not in the mood to become an early adopter. I'll try one more time after setting perms, but if I still have trouble, I'll wait another 3 months.

on the first command, i get error:

invalid predicate '-e'

same thing on the second command.

there's supposed to be a dash before 'type' right?

Rad wrote on Dec 26^th, 2010 at 10:44pm:

invalid predicate '-e'

Sorry, should be '-exec' not '-e'


Rad wrote on Dec 26^th, 2010 at 10:44pm:

there's supposed to be a dash before 'type' right?

Yes.

New command would be:
find ./ -type d -exec chmod 755

will try now. thanks.

check out last post this thread:

http://forums.cpanel.net/f34/php-files-not-running-my-server-141481.html

what do you think? you agree? dude sounds like he knows wtf he's talking about, no?

he says ths will give you a 500 server error:

Your PHP scripts are incorrectly set to permission 666 or 777

Your folders or higher level folders are incorrectly 666 or 777

Why error for setting perms HIGHER than necessary?

oops,  almost forgot to cd to modx directory first.

what would happen if i did?

will these commands go to *all* files & directories recursively?

error:


Quote:

find: missing argument to '-exec'

Rad wrote on Dec 27^th, 2010 at 12:39am:

find: missing argument to '-exec'

Sounds like your shell is using the strict version of find.  Try:

find ./ -type d -exec chmod 755 {} \;

The {} gets replaced the name of each file that was found.  The ; tells find where the end of the exec command is.  The \ escapes the ; so the shell passes it into the command instead of interpreting it itself.

As always, the man page can be your friend here.


Rad wrote on Dec 27^th, 2010 at 12:21am:

Why error for setting perms HIGHER than necessary?

For security reasons, some programs will refuse to operate on files with too permissive permissions.  This is especially true with critical security files such as the ssh authorized_keys file.


Rad wrote on Dec 27^th, 2010 at 12:35am:

oops,almost forgot to cd to modx directory first. what would happen if i did?

Yes, every file (or directory, depending on which command you ran) on the whole server would have its permissions changed.  You'd have errors all over the place afterward and there's no easy way to undo it.

my tech sppt guy says:

chmod -R 755 /home/user/public_html/absolute/path/modx

will do this. but how does it discrimnate between directories and files like yours does?

i would feel uncomfortable running that command.


MrMagoo wrote on Dec 27^th, 2010 at 3:00pm:

Yes, every file (or directory, depending on which command you ran) on the whole server would have its permissions changed.You'd have errors all over the place afterward and there's no easy way to undo it.

that's what i was worried about. the lesson there is > with great power (the shell) comes great responsiblity. i was always on high-alert using the shell. now i'm getting more comfortable > not so careful. i was getting tired, too.

red flag.

what do you know about Apache suEXEC? I am running that, I see. Is that good? Is that a default setting? Can't recall if I ever had that set/enabled.

find: type: No such file or directory
find: d: No such fle or directory

Rad wrote on Dec 27^th, 2010 at 7:41pm:

chmod -R 755 /home/user/public_html/absolute/path/modx will do this. but how does it discrimnate between directories and files like yours does?

It doesn't.


Rad wrote on Dec 27^th, 2010 at 7:41pm:

that's what i was worried about. the lesson there is > with great power (the shell) comes great responsiblity.

Yes, the shell has enough power to break things pretty quickly.  One thing that would make the command safer is to replace the "./" in the command with "/home/user/public_html/absolute/path/modx" or whatever the path is to the top level modx directory.  That way, you could run the command from anywhere and it would only run on that directory and sub-directories.


Rad wrote on Dec 28^th, 2010 at 12:22am:

find: type: No such file or directory find: d: No such fle or directory

Sounds like you forgot the "-" in front of type.  Try copying my command above and pasting it into your shell.  I copied and pasted the command into my own server and it worked fine.

Rad wrote on Dec 27^th, 2010 at 7:41pm:

what do you know about Apache suEXEC? I am running that, I see. Is that good?

It's good for what it is designed for, which is to allow a CGI script to run under a different user and group than apache itself is running under. 

http://httpd.apache.org/docs/1.3/suexec.html


Rad wrote on Dec 27^th, 2010 at 7:41pm:

Is that a default setting?

No, probably not.  If it is set up improperly, it can open some pretty big security holes.

nice catch / deduction on the dash before 'type'.

sorry 'bout that. funny, cuz i asked that exact question back in my reply #11.

yes, it worked, tho at first it appeared the FILE chmod didn't work .. until i refreshed the page. then all permissions were there as expected. whew.

it's really a beautiful thing when you know how to work the shell mojo. mojo is the name for the shell's power.

and .. modx revo installed .. slicker than you can say whale snot.

beautiful. not a single error.

thank-you, much.

as a little side-note, v5.8.8 is the most recent version of perl supported by cPanel, whereas v5.12.2 is the most recent version of perl. my host advised against upgrading past what cPanel supports.

in reflecting, the only thing i dont get is how your scripts work recursively without the -r

Rad wrote on Dec 30^th, 2010 at 1:13pm:

in reflecting, the only thing i dont get is how your scripts work recursively without the -r

In strictly technical terms, they aren't scripts.  'find' is a single command.  Everything else was parameters to the find command.  A script is a series of commands.  We just ran 'find' twice.

It works without the '-r' because find searches for files recursively by default, as opposed to many commands that only work on the current directory by default.  There are options we can pass the 'find' command to limit its recursive search to a set number of levels deep or to make it not follow symbolic links or to keep it from jumping file systems.  It's a very flexible command.  Check out the man page if you're interested.

MrMagoo wrote on Jan 2^nd, 2011 at 2:24pm:

In strictly technical terms, they aren't scripts.

Thanks. It's important to me I learn the lingo, correctly, cuz that indicates comprehension. I never heard anyone address the difference, but, to me, I just kinda considered a script as "a long string of geeky-characters we pass to the server" .. and a command was just a command. e.g. cp yada yada file.extension

But aren't we combining find with chmod? That's a different unix command, right?

Rad wrote on Jan 4^th, 2011 at 6:19pm:

But aren't we combining find with chmod? That's a different unix command, right?

chmod is the input for the '-exec' flag.  We're telling find to execute chmod 755 etc on every file it finds.  It's all one beautiful instruction. 

A script is usually several instructions saved in a text file and executed as a set.  Even a very long, complex command involving a few pipes isn't considered a script by most admins.  You have to do several commands in series, each relying on the results of the previous command, to make a script worth sharing.  One command, no matter how many things we pipe it to or how many arguments we pass it, isn't really a script.

This isn't entirely a bad thing.  If you can get something done in one command, you are doing it better than someone who writes a whole 10 line script to accomplish the same thing.

MrMagoo wrote on Jan 5^th, 2011 at 12:34am:

It's all one beautiful instruction.

got that right.  :)


MrMagoo wrote on Jan 5^th, 2011 at 12:34am:

Even a very long, complex command involving a few pipes isn't considered a script by most admins.

i learned something today.

MrMagoo wrote on Jan 5^th, 2011 at 12:34am:

A script is usually several instructions saved in a text file and executed as a set.

I wanted to expand on this because I'm not satisfied with my explanation.  I think it'll be clearer if I describe it this way:

Scripting is a lighter form of programing.  A script won't be a full program in that it probably won't have classes and objects and probably won't do very sophisticated error handling.  It should be like a program in that it uses some logic to step through the automation of a task.  So scripting is really a half-way step between single commands and full programs.

Also, I finally got my 1,000th post in.  ;D
I lurked for quite a while starting in probably early 2002 and then finally made myself a user name in 2005 after I posted my first guide.  Radified was one of a handful of sites I ran across while I was trying to get my tech wings underneath me, and I'm proud to be here giving back now.  Thanks to Rad for putting together such a great site and to all of your members for keeping it always interesting and enlightening.