This is why I implement the sudo command instead. this way I know I can't brake things.
I was in a linux shell last weekend ad I was very careful as I had to install things as root according to the directions. I have done an rm -r *.* when I have to but only when I know I have to to. One example is this. I was on an ftp server whos folders would not go away for some odd reason so I removed them that way. As for gorden's question when you get your shell back you know that something happened, weather it broke or not that's up to the command you did but just knowint that gives you piece of mind. but try installing the program under the sudo thing and be very careful when doing so. On Sep 8, 2014, at 5:22 PM, Travis Siegel <[email protected]> wrote: > Root is not generally the way you want to run commands. It is possible to > remove the entire contents of your hd as root, and with no prompting > whatsoever. You really shouldn't do anything as root unless it's absolutely > necessary. Running the command rm -r * will remove all files in the current > folder, and also, every file under any folders in that folder. If that > command were run from the root of your drive, and it was run as root, you'd > have a clean hd in short order, and your system wouldn't even tell you it > happened. Of course, the next ls command would alert you to the fact that > something was wrong, when you get a file or command not recognized error, but > by then, all your stuff is all gone, and can't be retrieved. > Use root for sysadmin tasks that cannot be performed by a standard user, and > leave everything else to standard users, the same rm -r * command executed > from root as a standard user would simply give a series of permission deneyed > errors instead of wiping out your entire hd. Of course, all your user files > would go bye-bye, but that's a far cry from wiping your entire hd, so always > be careful when you're logged in as root. > > > On Sep 8, 2014, at 1:20 AM, Sarah k Alawami wrote: > >> To add to my thing onthe terminal. YOU cannot brake anything.I wasin in a >> linode shell for 3 straight days as root and I did not brake a thing. >> >> Also the sudo command will let you be root for a short while for example >> >> >> sudo shutdown -s now >> >> or >> >> sudo shutdown -h +240 >> >> Hope that helps. >> >>> On Sep 7, 2014, at 23:22, Gordon Smith <[email protected]> wrote: >>> >>> Hi Esther >>> >>> Excellently explained, as always. This is a cross-platform application >>> which I’m trying to install. I can’t share any specifics at this point >>> owing to an NDA. But the developers say you need to be logged in as “Root” >>> in order to install it. Presumably, this relates to the permissions issue >>> which you raise in your post. Once the app is installed, you can do >>> everything from your own account so hopefully, it should only be necessary >>> to do this once. >>> >>> This has actually cause me quite a lot of frustration all day because I >>> need to get this done, and my woeful lack of Terminal experience is letting >>> me down badly yet again. I learned a few things when I installed and >>> configured Snow Leopard Server. But that was about fifty million years >>> ago, and I’ve probably forgotten most or all of it owing to the fact that >>> I’ve allowed myself to become very lazy in terms of installing software. >>> >>> OK, so let’s go back to your post. I can play the app anywhere on the >>> system, so if I log in as root, it can probably sit in the root directory >>> of the hard disk if that makes things simpler? >>> >>> I will go and re-read your post to see if I can get my head around what I >>> need to do. Once done, then it’s pretty much plain sailing from there on >>> in. >>> >>> Many thanks, as always. Incidentally, Esther, I refrained from contacting >>> you regarding your Mac Access mail account because we still have a record >>> of your settings here. So if it’s alright with you I’ll go ahead and >>> create a new account using those settings? If not, by all means get back >>> to us off list if you’d like to discuss this further. >>> >>> Many thanks again. >>> >>> Kindest regards >>> >>> Gordon >>> >>> On 7 Sep 2014, at 20:41, Esther <[email protected]> wrote: >>> >>> Hello Gordon, >>> >>> Shell scripts don't execute when invoked unless you have changed file >>> permissions on your system to allow them to execute. This is a security >>> precaution, because you don't, in general, want arbitrary scripts to run on >>> your system without your express permission, and by default the files you >>> create or copy will not have executable privilege. >>> >>> If I want to run a shell script from the Terminal command line, I first >>> make it executable: >>> >>> chmod +x scriptname >>> >>> If you only want the script owner to be able to execute the script, type: >>> >>> chmod u+x scriptname >>> >>> In this example, substitute the actual name of the script for "scriptname". >>> >>> Then, run the script with the command: >>> >>> ./scriptname >>> >>> The "dot" "slash" typed before the name of the script (with no spaces) >>> refers to the current directory, which is not usually included in your >>> $PATH (which are the directories that are searched by default for >>> executable files). >>> >>> Presumably the script takes care of the one-time installation, and you >>> won't use it again. >>> >>> Those two commands typed from Terminal -- the "chmod +x" before the >>> scriptname to make sure the file is executable and the "./scriptname" to >>> run the shell script file named "scriptname" should be all you need. >>> >>> Technically, you also need to allow "read" permission to a shell script >>> file in order to run it, but you already have it in most cases, including >>> the case you describe. The alternative to running the "chmod" command to >>> change the permissions mode of a file, if you have the file and directory >>> on another attached disk, is to copy the file with the "cp -p" option. >>> The "-p" switch preserves the permissions of the file you are copying, >>> which includes executable status for shell script files. >>> >>> HTH Cheers, >>> >>> Esther >>> >>> >>> >>>> On Sep 7, 2014, at 7:57 AM, Gordon Smith <[email protected]> wrote: >>>> >>>> Hello everybody >>>> >>>> I have a problem to which I’m hoping somebody can give me a definitive >>>> response. I have an application which I need to install on to a machine, >>>> but the application in question was ported from LINUX and installs via a >>>> shell script. When I open the script in the usual way, it is opening >>>> Xcode rather than installing as I had expected. Is this normal behaviour >>>> and, if so, is there a work-around? >>>> >>>> Many thanks. >>>> >>>> Gordon >>>> >>>> <--- Mac Access At Mac Access Dot Net ---> >>>> >>>> To reply to this post, please address your message to >>>> [email protected] >>>> >>>> You can find an archive of all messages posted to the Mac-Access forum >>>> at the list's public Mail Archive: >>>> <http://www.mail-archive.com/[email protected]/>. >>>> Subscribe to the list's RSS feed from: >>>> <http://www.mail-archive.com/[email protected]/maillist.xml> >>>> >>>> As the Mac Access Dot Net administrators, we always strive to ensure that >>>> the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and >>>> worm-free. However, this should in no way replace your own security >>>> strategy. We assume neither liability nor responsibility should something >>>> unpredictable happen. >>>> >>>> Please remember to update your membership preferences periodically by >>>> visiting the list website at: >>>> <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> >>> <--- Mac Access At Mac Access Dot Net ---> >>> >>> To reply to this post, please address your message to >>> [email protected] >>> >>> You can find an archive of all messages posted to the Mac-Access forum >>> at the list's public Mail Archive: >>> <http://www.mail-archive.com/[email protected]/>. >>> Subscribe to the list's RSS feed from: >>> <http://www.mail-archive.com/[email protected]/maillist.xml> >>> >>> As the Mac Access Dot Net administrators, we always strive to ensure that >>> the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and >>> worm-free. However, this should in no way replace your own security >>> strategy. We assume neither liability nor responsibility should something >>> unpredictable happen. >>> >>> Please remember to update your membership preferences periodically by >>> visiting the list website at: >>> <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> >>> >>> <--- Mac Access At Mac Access Dot Net ---> >>> >>> To reply to this post, please address your message to >>> [email protected] >>> >>> You can find an archive of all messages posted to the Mac-Access forum >>> at the list's public Mail Archive: >>> <http://www.mail-archive.com/[email protected]/>. >>> Subscribe to the list's RSS feed from: >>> <http://www.mail-archive.com/[email protected]/maillist.xml> >>> >>> As the Mac Access Dot Net administrators, we always strive to ensure that >>> the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and >>> worm-free. However, this should in no way replace your own security >>> strategy. We assume neither liability nor responsibility should something >>> unpredictable happen. >>> >>> Please remember to update your membership preferences periodically by >>> visiting the list website at: >>> <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> >> <--- Mac Access At Mac Access Dot Net ---> >> >> To reply to this post, please address your message to >> [email protected] >> >> You can find an archive of all messages posted to the Mac-Access forum at >> the list's public Mail Archive: >> <http://www.mail-archive.com/[email protected]/>. >> Subscribe to the list's RSS feed from: >> <http://www.mail-archive.com/[email protected]/maillist.xml> >> >> As the Mac Access Dot Net administrators, we always strive to ensure that >> the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and >> worm-free. However, this should in no way replace your own security >> strategy. We assume neither liability nor responsibility should something >> unpredictable happen. >> >> Please remember to update your membership preferences periodically by >> visiting the list website at: >> <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> > > <--- Mac Access At Mac Access Dot Net ---> > > To reply to this post, please address your message to > [email protected] > > You can find an archive of all messages posted to the Mac-Access forum at > the list's public Mail Archive: > <http://www.mail-archive.com/[email protected]/>. > Subscribe to the list's RSS feed from: > <http://www.mail-archive.com/[email protected]/maillist.xml> > > As the Mac Access Dot Net administrators, we always strive to ensure that the > Mac-Access E-Mal list remains malware, spyware, Trojan, virus and worm-free. > However, this should in no way replace your own security strategy. We assume > neither liability nor responsibility should something unpredictable happen. > > Please remember to update your membership preferences periodically by > visiting the list website at: > <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> <--- Mac Access At Mac Access Dot Net ---> To reply to this post, please address your message to [email protected] You can find an archive of all messages posted to the Mac-Access forum at the list's public Mail Archive: <http://www.mail-archive.com/[email protected]/>. Subscribe to the list's RSS feed from: <http://www.mail-archive.com/[email protected]/maillist.xml> As the Mac Access Dot Net administrators, we always strive to ensure that the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and worm-free. However, this should in no way replace your own security strategy. We assume neither liability nor responsibility should something unpredictable happen. Please remember to update your membership preferences periodically by visiting the list website at: <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/>
