Re: How to edit a read-only file

On Wed, 04 Jan 2006 14:30:57 +0100, "Enrique Perez-Terron" <enrio@xxxxxxxxx>
wrote:

<On Wed, 04 Jan 2006 11:04:23 +0100, Enrique Perez-Terron <enrio@xxxxxxxxx> wrote:
<
<> On Wed, 04 Jan 2006 03:31:07 +0100, Jay <jasonanderson042@xxxxxxxxxxxxxxxxxx> wrote:
<>
<>> On Tue, 3 Jan 2006 23:25:36 +0100, "Peter T. Breuer" <ptb@xxxxxxxxxxxxxxx>
<>> wrote:
<>>
<>> < 1) are you working as root?
<>>
<>> Don't know.
<>
<> You need to run the command
<>
<> su -
<>
<> and answer the password prompt. Then you "become root", i.e., you will be
<> running a shell owned by user "root", which has the widest privileges
<> to override permission bits. When you are done with the things that
<> require such privileges, say
<>
<> exit
<>
<> and you are back in the original, limited shell.
<
<I forgot to say that any program you start from the root shell, will "run
<as" root, and have the same privileges.
<
<If you start an editor from the root shell, it will be able to overwrite
<the config file. It does not really matter if the editor is a gui
<editor with its own window, menus, etc, or a terminal window editor
<like vi.
<
<When you start a gui editor from the desktop, the gui editor runs with
<the same privileges as the desktop program itself. This is not a defect
<of the gui editor.
<
<It is in fact good practice to always run the desktop as an unprivileged
<user (as you have been doing), and only invoke "root" privileges when
<you need it. Just imagine what could happen if you start a web browser
<that inherits root privileges, and the browser executes java or
<javascript code from a remote web site. You would be giving the remote
<web designers full control over your computer. Browser designers try to
<prevent the most obvious security holes, but as long as browsers want to
<be very powerfull, capable of downloading stuff, saving cookies,
<understanding a zillion graphics formats, etc, it is unaviodable that
<some holes remain. Or think of Windows users who download and install
<updates through the browser. That means the browser must overwrite all
<system files! How exacty would you draw the line between the what the
<browser shall be allowed to do and what it shall not. There are
<solutions to all this, at least in theory, but don't expect browsers
<to implement such solutions perfectly for the first century or so.
<
<You have certainly noticed that some posters here say, for Gods sake,
<don't use the Gui. That is questionable, but for one, the command line
<tools constitute the traditional way, the common denominator, the shared
<knowledge. Graphical tools are mostly thin layers over the command line
<tools, i.e. they invoke the command line tools behing the scene. They
<are generally fairly recent, poorly tested, often peculiar to a
<particular distribution, so few people know them. It is also hard to
<cut and paste a graphical tool session and post it to the newsgroup.
<That is easy to do with the terminal window dialogue. The graphical
<tools generally hide their configuration data, and are also poorly
<documented. You are not supposed to know what all those wires and
<valves under the hood do, since the graphical tool is supposed to be
<"easy". If only you never had to look under the hood! The traditional
<configuration files are well known and easy to post in the newsgroup.
<
<-Enrique

Thanks for your time. I think what happened was that the file I was working on
was immutable. I needed to drop text files to a sub directory. To write files I
needed permissions, I needed to learn how to navigate. As I spent more time and
worked through it, posting to usenet, searching, observing, things came better
into focus.

If I didn't post readouts from familiar tools and rather talked in generalies,
it was because I was still learning the basic concepts and the tools. I ended up
using vi. I found a reference page on the web that had the 3 or 4 commands I
needed to do the job
http://www.comptechdoc.org/os/linux/usersguide/linux_ugvi.html

I didn't care gui or console, but I was disappointed at how far my comand line
skills had eroded. This was fun, a worthwhile exercise for sure. Part of the
problem is the laptop. It appears to be a pseudo-windows machine. I eventually
did get debian sarge installed but it wouldn't do x, no screens, video problems.
Had tried ubuntu, got screens, it won't network. Knoppix, with a start up
qualifier noapic, fine but I want to do a regular distro.

I'm going to shift to a more compatible desktop box and stop working on the
laptop.

Thanks again, it all helped.
-jay.
.

Relevant Pages

  • A python IDE for teaching that supports cyrillic i/o
    ... first programming language to high school students? ... I believe that using a editor + command line will only make ... So a student that have written a script in a GUI editor and saved ...
    (comp.lang.python)
  • bringing ee up to date
    ... -is a simple screen oriented text editor. ... +.\" To format this reference page, use the command: ... -Turn off display of information window at top of terminal. ... -.Ss "Control keys" ...
    (freebsd-hackers)
  • Re: Typography
    ... Sounds more to me as if there wasn't a straightforward LaTeX ... which editor to use. ... There never would have been one standard - obviously. ... old command line stuff had had its day. ...
    (uk.comp.sys.mac)
  • Re: Difference between VC++ and UNIX
    ... grammar that describes how you interact with the editor. ... One way to think of this is that every command you can give the editor ... if I type C-x in emacs, that puts me in a state where typing "u" ... will be in a state where a keypress inserts the literal character. ...
    (comp.programming)
  • vi editor FAQ (Frequently Asked Question List), Part 2/2
    ... has the UCB distribution of vi, and lots of useful macros. ... m0 is the ex command to move the line to line 0. ... Swap character and one vertically above: ... A non-visual editor under Unix. ...
    (comp.unix.questions)