25 Nov, 2008, Igabod wrote in the 1st comment:
Votes: 0
i downloaded a copy of EmberMUD here and finally got around to looking at it last night. the funny thing is that i've been fiddling around with keggermud lately and when i looked at embermud i just about laughed myself stupid cause i had basically turned keggermud into a VERY sloppy embermud and it took me 2 months of work. i will say that embermud is MUCH more newbie-coder friendly than any other codebase i've seen yet. it is extraordinarily well commented and most of the changes any newbie admin would make are all located in the config.h file. i've run into a problem however with the version 0.9.47 release of it. it is read-only and i'm not sure how to change this. i would LOVE to be able to play with the code but all the changes i make are unsaveable. i tried right clicking the files and editing the properties to change it from read-only and still i'm unable to make changes to any files. i'm sure i remember running into this problem years ago and the solution was something with the chmod command in the shell but i'm unable to remember exactly what to do. if somebody could help me with this i'd appreciate it very much. thanks in advance.
25 Nov, 2008, David Haley wrote in the 2nd comment:
Are you in Linux/Cygwin? Just do: chmod u+w *.c *.h
25 Nov, 2008, Igabod wrote in the 3rd comment:
thank you david that did it. w = write what's the u mean?
25 Nov, 2008, David Haley wrote in the 4th comment:
"u" means "user". You can specify read/write/execute permissions for the owner user, the owner group, and everybody else. So saying "u" means the owner user, "g" means that owner group, and "o" means "other people".
26 Nov, 2008, Igabod wrote in the 5th comment:
so basically if i were on a shell with multiple login names for the same account i would use the g and avoid the e so that not every person and their mother could edit the mud? not that i really have to know this right now since i'm doing all this on cygwin but it's good to know these things.
26 Nov, 2008, David Haley wrote in the 6th comment:
If you wanted multiple people to work on the files, then basically yes, you would put all these users in the same group, and then set g+rw. If you didn't want other people to read the files, you would set o-rwx (prevent others from reading, writing or executing).
26 Nov, 2008, Igabod wrote in the 7th comment:
good to know. why aren't any of these listed on chmod –help ?
26 Nov, 2008, Igabod wrote in the 8th comment:
i think i found a bug with the olc on embermud, whenever i set a mob to have the act_gain flag and then do a hotboot (should be copyover but oh well) the mud freezes up and i get the following error message scrolling down the screen in cygwin: Write_to_descriptor: Bad file descriptor. what is the problem here? oh yeah and i haven't tried this with any other act_ flags so it may not just be act_gain.
26 Nov, 2008, quixadhal wrote in the 9th comment:
Here's a good place for me to pipe up with a subtle aspect of the unix file protection system that isn't obvious.
Using the symbolic form of chmod, you get rwx bits for user, group, and other. For files, the meanings are pretty clear. Execute access means you can directly invoke the file. Read access means you can read it. If it's a script, you need read access, but lacking execute access requires you to be able to invoke the script parser. So, if I write a perl script and do chmod 740 on it (numeric form), I can do anything to it, people in my group can read it but not directly invoke it, and the world is shut out. However, having read access, if the group members can invoke perl itself, they can pass the script as an argument and run it that way.
That's not the subtle part though. :)
The subtle part is what those bits mean for directory access. Write access does not prevent you from writing to files, it prevents you from writing to the directory itself. Thus, you can't create NEW files, nor can you delete files, but you can edit existing files you have write access to. Read access, likewise, allows reading the directory – not the files. If I omit read access, you can't do an ls to get the contents, but if you already know a file exists AND have access to it, you can access it. FTP upload directories used to be setup as writable but not readable. Finally, the execute bit for a directory, means you have access to things IN the directory. If you omit that,
it shuts off access entirely, even if you have read/write permissions to the directory itself.
We used to always get questions by people who did a chmod 700 to their home directory and wondered why nobody could access their web pages (at ~/public_html), even though they were set to 755. The correct way would be to set your home directory to 711.
I typically have a pair of macros/functions/whatever that do:
find . -type d | xargs chmod 755
find . -type f | xargs chmod 644
Substitute the permissions you want, but the idea is you usually want execute on directories, but not on files unless they really are executable. :)
Using the symbolic form of chmod, you get rwx bits for user, group, and other. For files, the meanings are pretty clear. Execute access means you can directly invoke the file. Read access means you can read it. If it's a script, you need read access, but lacking execute access requires you to be able to invoke the script parser. So, if I write a perl script and do chmod 740 on it (numeric form), I can do anything to it, people in my group can read it but not directly invoke it, and the world is shut out. However, having read access, if the group members can invoke perl itself, they can pass the script as an argument and run it that way.
That's not the subtle part though. :)
The subtle part is what those bits mean for directory access. Write access does not prevent you from writing to files, it prevents you from writing to the directory itself. Thus, you can't create NEW files, nor can you delete files, but you can edit existing files you have write access to. Read access, likewise, allows reading the directory – not the files. If I omit read access, you can't do an ls to get the contents, but if you already know a file exists AND have access to it, you can access it. FTP upload directories used to be setup as writable but not readable. Finally, the execute bit for a directory, means you have access to things IN the directory. If you omit that,
it shuts off access entirely, even if you have read/write permissions to the directory itself.
We used to always get questions by people who did a chmod 700 to their home directory and wondered why nobody could access their web pages (at ~/public_html), even though they were set to 755. The correct way would be to set your home directory to 711.
I typically have a pair of macros/functions/whatever that do:
find . -type d | xargs chmod 755
find . -type f | xargs chmod 644
Substitute the permissions you want, but the idea is you usually want execute on directories, but not on files unless they really are executable. :)
26 Nov, 2008, David Haley wrote in the 10th comment:
It's listed in my manpage for chmod, although in the middle of one big paragraph and not very clearly laid out.
And with all the fun Quix mentioned, throw in the sticky bit on directories, and then you have to look at both the sticky bit, owners, and permissions to figure out who can do what. :wink:
And with all the fun Quix mentioned, throw in the sticky bit on directories, and then you have to look at both the sticky bit, owners, and permissions to figure out who can do what. :wink:
Random Picks
