|
CO527 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
Relating to Question 98 (2004). So:
/bin/wfln /HELLO.TXT "Hello Everyone"
creates a file called "/HELLO.TXT" with "Hello Everyone" in the file ? or does "wfln" just create a file and not add anything whatsoever in it ? Could you please please please... (I'm really begging here) type a sucessfull operation of "wfln" ? Thanks.
Close, but due to the way options are processed, you'll actually get "HelloEveryone" in the file (plus the quotes either side). The MOSS console ("/bin/console", "moss/modules/UConsole.java") does not deal with quoted arguments.
For an example of "wfln" operation:
MOSS# /bin/wfln /foobar hello MOSS world
MOSS# cat /foobar
helloMOSSworldMOSS# /bin/wfln /foobar zog
MOSS# cat /foobar
zogloMOSSworldMOSS#
note the lack of a newline on the end of the file, so when it's displayed (using "/bin/cat") the console prompt appears at the end, not neatly on the next line.
Keywords: moss2004
I need you to to please comment the "UCat", "UMkdir" and "UWfln" a bit more just to try and understand it more. Try and comment the parts that does something just to really understand your code is a pain in the ass. Explain wat the each command does. It will really help rather than just reading all the 1000 lines of codes figuring what you are trying to write.
I've added comments to two of the utilities: UCat and UWfln. The level of comment is probably slightly excessive. E.g. commenting the fact that something reports an error and exits, when that's clearly what the code does, is not really necessary. If you don't know what a particular method does, look at the documentation. These utilities are mostly less than 200 lines of code a piece, which is pretty small in the context of operating systems.
Keywords: moss2004
So lets get this straight, we have a assignment based in a program that won't exit unless you crash it, is missing a method that should have been included, has non-descriptive method names, has poor if any commenting, is not possible to work on off site, unless you have Linux, or have set up a vpn, a raptor account, and want to compile from a command line.
Just a guess but we are the first year that has this assignment aren't we.
Last year's cohort had a fairly similar assignment, which is largely obvious if you look around in the anonymous questions pages a bit.
For your first point, of "won't exit unless you crash it", this is not entirely true. To exit MOSS you do not need to crash it, which implies generating some sort of run-time error, in effect, "blue-screen"-ing it. I could have implemented this, or the even simpler "System.exit (0)", but having code like that in a MOSS program (such as "/bin/console") would be logically wrong. The correct approach, which isn't implemented yet, would be to include a suitable "/bin/shutdown" utility, that calls some "MPosixIf.shutdown()" method which ultimately causes the MOSS kernel to exit. I figured that people would be happier using ctrl-C to exit MOSS (or resetting the JVM in BlueJ), rather than typing in "/bin/shutdown"..
In response to your second point, yes, that was my fault. But bear in mind that this only affects a small part of one of the options. Even without this method, it would still be possible to implement a mostly functional copy program (with just the append operation being deficient).
As for non-descriptive method names, an example ? The method names are pretty descriptive, plus most of them have JavaDoc wrapping describing their function, parameters and return-value.
On commenting, it's only a collection of the end-user utilities (things in "moss/modules/") that are poorly commented. The rest of MOSS is pretty well commented. It is expected that you can read and understand general programming constructs like variables, loops, conditionals, etc.
It is quite possible to work on this off-site, without Linux. You'll need an up to date version of BlueJ though. One of the comments from last year was related to compiling and running MOSS on raptor. Which is why this year I put together fairly extensive instructions on how to do this.. Compiling from a UNIX command-line isn't hard -- you just type "make". Everyone doing this module should have a raptor login. Well, if anybody hadn't, I would have expected them to say something by now (since the web-page is written assuming you do have a raptor login), and nobody has.. You were advised early on to compile and run MOSS on raptor, so as to get familiar with this process. If you've left it to the last minute, that's not my fault..
How do I make the operating system prompt the user for an input ?
See the answer to Question 72 (2004).
Keywords: moss2004 , moss2004-1
Could you give me the link to that rent a coder site you mentioned ? cheers.
Erm, nope. But you don't have to look very hard.. If you're good enough to earn money coding for other people, you should be able to find the site yourself. ;-).
I was just reading through the anon questions but it seem the link from question 60 to question 80 are linked to questions 40 to 60 and cannot access question 60 to 80.
Hit refresh on your browser a bit. The pages are generated such that the most recent 20 questions all appear on a single page, but as more questions are added, the page that contains the most recent questions "moves" (every 20 questions at the moment).
Hi, I'm just asking about the sucessful operation of UCopy. So if I type:
/bin/copy -a /SOURCE /DEST
MOSS should append the details of "/SOURCE" to "/DEST", but if I type:
/bin/copy /SOURCE /DEST
my MOSS should create or overwrite "/DEST" with "/SOURCE" details ? But:
/bin/copy -i /SOURCE /DEST
should tell me if the destination file already exists, (but not create the file if it does or do anything about it, but if it doesn't exist create the file, or is "-i" strictly for information only)?
Beware of terminology, "details" is a bit vague -- do you mean file creation date, inode number, what ? "the contents of" is what is actually being referred to. For the append operation, yes, you are thinking correctly there. The "-i" means "interactive"; from the assignment description "support an "-i" option, that prompts the user for confirmation if the destination file already exists.". So in the case where "/DEST" already exists, it should tell the user that, and ask them if they wish to overwrite (or append). If "/DEST" does not exist, it shouldn't ask the user anything -- just create the file and write to it. Note that the append option won't have any effect in the case where "/DEST" does not exist -- it'll still just create and write to it.
Keywords: moss2004 , moss2004-1
How do I get MOSS to exit from the putty command line, so I can go back and compile it without having to re-open putty?
You should just be able to press ctrl-C, and get the raptor command-prompt back..
Keywords: moss2004
I am doing option 1, and was wondering if we are expected to cope with filenames that contain spaces ?
Nope, you do not need to deal with this -- in fact, you probably can't deal with this (not easily anyway). For instance, if I did:
MOSS# /bin/copy "/My Stuff/blah" /tmpfile
Then what UCopy gets are 4 arguments: '/bin/copy', '"/My', 'Stuff/blah"', '/tmpfile' -- i.e. the console (that gives you the "MOSS# " prompt) doesn't cope with quoted arguments. The downside is that you can't read from files that contain spaces in them from the host file-system, but I'm not worried about that. It's generally accepted that having spaces or other funny characters in filenames is a bad idea (Microsoft do not help here).
Keywords: moss2004 , moss2004-1
For option 1: Is it safe to say that we need not worry about the attributes of the files copied using UCopy ? or should we check them too, to make sure ?
Yes, it's safe to ignore the attributes (permissions) of files (MOSS does so anyway in most cases). Normally one would expect a copy program to preserve the permissions of the file being copied (i.e. read/write/execute, owner, group, etc.) but that's not necessary here. More to the point, actually setting some of this information for a file is not currently possible.
Keywords: moss2004 , moss2004-1
Hi, just wanted to know if you would like the UCopy facility to take all 3 arguments together (or just the 2 you mention). Also, how should the user input more than one option:
/bin/copy -ia source target
or:
/bin/copy -i -a source target
or:
/bin/copy [<options>] source target
Don't quite understand your first question -- the copy command takes at least two arguments, possibly more. But these are different arguments; they shouldn't be combined. Your last example for multiple arguments is more the formal specification, where "[options]" means "optional options" (square brackets denote optional things, angle brackets denote required things, or so the convention goes). For multiple options, specifying them separately is fine -- e.g. as in your second example. But, I certainly won't object to code that allows short options to be specified together! -- e.g. as in your first example.
Keywords: moss2004 , moss2004-1
Hello. I'm struggling to figure out how to distinguish between a file and a directory. It's just on Question 78 (2004), you use "/foo" as a file name, and on Question 47 (2004) you use "/tmp" as a directory. I don't quite get how to check between the two. Thanks.
Checking to see whether something is a file or a directory can be done in one of three ways:
One of these is probably more appropriate than the others..
Keywords: moss2004
Referrers: Question 114 (2004) , Question 127 (2004)
In option 5, process priority, how do we know how important a process is ? So that we can set it to run first. Is it just done randomly to show that it can be done or is there a method or something that I am missing that lets you know its importance ?
The priority of a process should be known absolutely -- the first part of this option is to add that field to the process data-structure. The thing that sets this field is "MPosixIf.setpriority()", called from user-processes. At the moment, a program may only change its own priority -- it may not change the priority of other processes. The mentioned test program ("/bin/busyloop") tests the priority implementation by running 5 processes at different priorities -- higher priority processes should complete before the lower priority ones.
Keywords: moss2004 , moss2004-5
Following from Question 112 (2004), can you be a bit more specific as to what the "mode" attribute represents with reference to a file or directory. The comments say "protection", but thats a bit vague. I've tried it on various test data and it throws up numbers round about 16000 for directories and 33000, but nothing consistent.
This "MInode.node" field is a set of "bitfields", i.e. the value itself is fairly meaningless. What's important is what bits in there are set or not set.
Something that has cropped up is people's relative inexperience using such bitfields. The useful bitwise operators are "|" (bitwise or), "&" (bitwise and) and "^" (bitwise exclusive or). The uses are thus: bitwise-or is used to combine flags; bitwise-and is used to mask a flag out (e.g. to see if it's set); bitwise-xor can be used to "flip" a bit. Bitwise-not, "~", is used to invert the bits. As an example, the "mode" field can be tested for, say, a regular file or directory, using:
if ((ino.mode & MFileOps.S_IFREG) == MFileOps.S_IFREG) {
MPosixIf.writestring (MPosixIf.STDOUT, "It's a regular file!\n");
} else if ((ino.mode & MFileOps.S_IFDIR) == MFileOps.S_IFDIR) {
MPosixIf.writestring (MPosixIf.STDOUT, "It's a directory!\n");
} else {
MPosixIf.writestring (MPosixIf.STDOUT, "It wasn't a file or directory :O\n");
}
Keywords: moss2004 , moss2004-1
Referrers: Question 118 (2004)
When the user passes in invalid arguments, what should the proper response be ? "MPosixIf.exit (1)" or "return 1". The question here is what constitutes an 'error' ?
Either is acceptable, providing you're talking about "return 1" in the "main()" method. In deeper-level methods, it is probably easiest to just say "MPosixIf.exit (1)" (which is like the similar Java "System.exit (1)", but for MOSS processes rather than Java virtual machines).
Keywords: moss2004
Hello. I'm having a little trouble with the interactive feature. I'm checking the file exists using "MPosixIf.stat()" and checking if what is returned is 0, and if it does I'm displaying the prompt, but the prompt is also being displayed when the file doesn't exist and I cannot figure out why. Also when i type 'n' to respond to the prompt it is still copying even though in my code I check for an 'n' and request that it exits using "MPosixIf.exit(1)". Thanks.
I can only presume that something is broken in your code.. "MPosixIf.stat()" will return 0 if the file exists, or something such as "-MSystem.ENOENT" if it does not. If the prompt is being displayed in the case where the file does not exist, the logic of your code must be wrong.. Similarly for the handling of user-input -- if you call "MPosixIf.exit(1)", the program will definitely exit. Try putting in print statements at various points in your code to display the return values of things like "MPosixIf.stat()", and show the route being taken through the code. This should help you identify what/where the problem is.
Keywords: moss2004 , moss2004-1
Hello, I'm just trying to use the "MPosixIf.lseek()" method to seek to the end of the file, I'm not sure if I'm implementing it right - I always get an error saying bad file descriptor:
fdAppFle = MPosixIf.open (argv[i], MFileOps.OPEN_WRITE);
fd2 = MPosixIf.lseek (fdAppFle, 0, MFileOps.LSEEK_END);
fd3 = MPosixIf.write (fd2, buf, buflen);
I'm opening "fdAppFle", then seaking the to the end of the file (fd2) before writing to the file (fd3).
Follow the logic of your code more carefully..: the first line is good. This opens the file specified by "argv[i]" for writing, and returns a file-descriptor (or error) that you assign into "fdAppFle". The next line is mostly correct -- i.e. it seeks to the end of the file successfully. But the value returned by "MPosixIf.lseek()" is not a file-descriptor -- it's the new absolute offset within the file. In this case, where you're seeking to the end of the file, it'll return the file-size. You then try and use this value (assigned to "fd2") in a call to "MPosixIf.write()", which will definitely throw up an error. The file-descriptor you actually want to write to should be the same one that "MPosixIf.open()" returned and the one on which you did "MPosixIf.lseek()".
Note that since neither "MPosixIf.lseek()" or "MPosixIf.write()" return file-descriptors, assigning them to variables such as "fd2" and "fd3" doesn't make much sense..! (given that "fd" is usually an abbreviation for "file-descriptor" in code).
Keywords: moss2004 , moss2004-1
Referrers: Question 140 (2004)
In your example of how to detect a file or directory (Question 114 (2004)):
if ((ino.mode & MFileOps.S_IFREG) == MFileOps.S_IFREG) {
MPosixIf.writestring (MPosixIf.STDOUT, "It's a regular file!\n");
} ...
According to the doc, there is no fields called "S_IFREG" or "S_IFDIR" ? Neither does it compile.
I made a small error there, although it should be within your capability to search the code for these constants and fix the error. These constants are in "MInode", not in "MFileOps", so that chunk above really should have been:
if ((ino.mode & MInode.S_IFREG) == MInode.S_IFREG) {
MPosixIf.writestring (MPosixIf.STDOUT, "It's a regular file!\n");
} ...
Keywords: moss2004 , moss2004-1
I'm not sure how to use "MPosixIf.stat()" - this is how I use it:
MPosixIf.stat(argStore[i], MInode.size)
it wont let me use it - complains with an error saying "cannot resolve variable MInode" (this is for the -i operation). thanks.
You need to pass it a new "MInode" object, which it set the fields in. No different from returning an MInode, really, except that it would have broken the "int" return-type convention. The correct way to use "MPosixIf.stat()" would be something like:
MInode ino = new MInode ();
res = MPosixIf.stat (filename, ino);
That leaves "ino" populated with information about the file, or undefined (if the stat failed).
Keywords: moss2004 , moss2004-1
I have extracted and compiled MOSS via putty, and placed it into my home directory, I ran it from home, and checked it with my compiler, and it worked fine, but I tried to carry on my work at uni, and when I tried to compile my file in raptor it said that I was missing the moss kernal, and nothing would compile, is this another bug?
Nope, this isn't a bug. More likely you don't have the rest of the MOSS software on raptor, so like any large program, you're not going to get very far just trying to compile a standalone piece of it. You need to unpack/install MOSS on raptor as per the instructions, then copy your own file into that source tree, then compile it.
Keywords: moss2004
|
Maintained by Fred Barnes, last modified Thu May 8 12:58:04 2014 |
