Why doesn't every operating system have a program like this?

[chrisname]

sizeof.c

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

/* sizeof: given a file in argv[1], use stat(3) (sys/stat.h) to get the file's * size, and then print it */ #include <stdio.h> #include <sys/stat.h> int main(int argc, char** argv) { struct stat f; size_t fsize = 0; if (argc < 2) { fprintf(stderr, "usage: %s <file>\n", argv[0]); stat((const char*)argv[0], &f); fsize = (size_t)f.st_size; printf("Example:\nFile %s; size: %ld bytes\n", argv[0], fsize); return 1; } stat((const char*)argv[1], &f); fsize = (size_t)f.st_size; printf("File: %s; size: %ld bytes\n", argv[1], fsize); return 0; }

$ ./sizeof sizeof.c File: sizeof.c; size: 611 bytes --- $ ./sizeof usage: ./sizeof <file> Example: File: sizeof.exe; size 18897 bytes

It works perfectly under Cygwin or on *NIX. So why doesn't every operating system in the world ever created ever have something like it?

In fact, all of them should just come with this (and a POSIX subsystem).

[Disch]

seems silly to boot up the command prompt, cd to the directory containing the file, type out the program and filenames...

when you can just highlight the file in question and view the size in the status bar.

Then again I never did understand *nix/commandline masochism

[chrisname]

But... but... it's useful!

And this version accepts an arbitrary number of files:

/* sizeof: given a file or files in argv, use stat(3) (sys/stat.h) to get the
 * size of each file, and then print it.
 */

#include <stdio.h>
#include <sys/stat.h>

int main(int argc, char** argv) {
    struct stat f;
    size_t fsize = 0;
    int i = 0, tmp = 0;
    
    if (argc < 2) {
        fprintf(stderr, "Usage: %s [file1 .. filen]\n", argv[0]);
        
        stat((const char*)argv[0], &f);
        fsize = (size_t)f.st_size;
        
        printf("Example:\n\tfile %s\n\tsize: %ld bytes\n\n", argv[0], fsize);
        return 1;
    }
    
    printf("Files:\n");
    
    for (i = 1; i < argc; i++) {
        stat((const char*)argv[i], &f);
        fsize = (size_t)f.st_size;
    
        printf("\tfile: %s\n\tsize: %ld bytes\n\n", argv[i], fsize);
    }
    
    return 0;
}

hahahaha! Fear me and my pointless 33-line programs! I dare you to compile it in cygwin, put it in your system32 directory, open a command prompt and type "sizeof %WINDIR%\System32\*.exe"

I might even make a third version, which sorts the files alphabetically into a file list! Are you scared?

AND it works on directories! (that's one thing the windows shell doesn't do, btw).

Edit: sorry for the indentation, notepad++ (which I no longer capitalize, because it's annoying) doesn't have an option to use spaces instead of tabs for auto-indenting (gedit does); but gedit doesn't have syntax highlighting for ASM, so I need to use notepad++. What a pickle...

[Disch]

(that's one thing the windows shell doesn't do, btw).

Right click, properties

notepad++

No IDE?

Masochist.

=P

[gcampton]

chrisname wrote:

AND it works on directories!

Shame they would always come back with the same byte size :P
ok ok, I'm gunna make a new post cause I'm curious. brb.

[helios]

Use an orthodox file manager. Trust me, for most file operations, it's much faster than the command line. For example, getting a directory's size is a single spacebar press.
I've considered writing a Total Commander clone that behaves consistently across platforms. Krusader is fairly close, but still has some differences in behavior that slow me down. Most notably, quick search, which I use to death.

EDIT: Oh, yeah, also ls and dir.

[gcampton]

Shame they would always come back with the same byte size :P

Aren't unix directories just files anyway, so there size would not change directory to directory. they would pretty much all be the same 2kb or so... ?

OT
got anything useful for your environment I can use?
http://cplusplus.com/forum/lounge/18609/

[chrisname]

Aren't unix directories just files anyway, so there size would not change directory to directory. they would pretty much all be the same 2kb or so... ?

Then why would you need dirent.h and why would there be an

EISDIR - Is a directory

?

Also, you're right; directories do all return the same size. Why is that? I thought UNIX directories were structured something like this:
filename filesize starting block ending block

EDIT: Oh, yeah, also ls and dir.

I think it's quicker to type "sizeof <file>" and read 2 lines of output than to go to a directory that could potentially contain thousands of files (not enough to fit on a scrollable terminal, let alone a vmode 3 screen), find the one you're looking for, and read it's size. True, you can use ls | grep <part of filename> but then, isn't it quicker to type sizeof <filename>? Also, if you wanted to use with ls and grep in this scenario, you would have to do it multiple times; for example:
Have a file called myFile and another called myOtherFile. However, there is also a lot of other files in the directory that begin with "my." So you would do

ls | grep myF
ls | grep myO

When you could just type
sizeof myFile myOtherFile?

Right click, properties

Or you could just type "sizeof <dir>"

[gcampton]

I'm not sure exactly how directories are structured, But I know you can open them up in VIM (did that by mistake one day), so probably worth having a look at.

[chrisname]

Hmm... ok.

[blackcoder41]

Right click, properties

LOL!

[gcampton]

bet I can type "sizeof path_to_filename" faster than you can open up explorer cd and right click, left click properties :P

[blackcoder41]

how about long file names?

bet I can type "sizeof path_to_filename" faster than you can open up explorer cd and right click, left click properties :P

i would be glad to accept that challenge if we were in the same place.. ^ ^

[chrisname]

So you're telling me you can
1. click start
2. type "explorer" and hit enter
3. click the path bar
4. type C:\Windows\System32 and hit enter
5. find and right-click cmd.exe
6. left-click properties
faster than I can
1. click start
2. type "cmd" and hit enter
3. type "cd C:\Windows\System32" and hit enter
4. type "sizeof cmd.exe"

Here's a video to prove you (probably) can't:
http://www.mediafire.com/?kjzmxnnmudg

I cut out the part where I switched from recording the lower left corner of the screen to inside the cmd window; but I made up for that by having to switch from the recording program's window to the cmd window manually. All in all, it takes me less than 8 seconds. Oh yeah, and I cut out cd'ing from my "documents" directory to the C:\ directory, but I don't see that that makes any difference. Plus I have cold hands.

Here's my attempt at doing it from your end.
http://www.mediafire.com/?amy53jkynqz

Well, would you look at that. 28 seconds, including loading times, vs. 8 seconds, also including loading times. Conclusion: me and gcampton are right, going through the command line is faster for certain things.

[Disch]

I won't disagree that keyboard is faster than the mouse. In fact I prefer to use the keyboard whenever practical for that very reason.

But come on.

me and gcampton are right, going through the command line is faster for certain things.

Assuming you know the exact name of every path in the diretory tree, have whatever cryptic commands you need (and any arguments they take) memorized, and don't mistype anything, then yes, you're right.

Also.. typing in Dvorak is faster than typing in Qwerty, but is equally ridiculous.

Also, who boots explorer from the start menu? Don't you have shortcuts to common directories in the launcher on your taskbar? Do you at least have a cmd shortcut since you appreantly use it a lot? Or do you actually go to Run every time?


This is what I never understood. People put themselves through such hardship to shave 5 seconds off an arbitrary task that seldom ever comes up. The time it takes to learn how to do all this (bundled with the time wasted on mistyped commands/mistakes/etc) is undoubtedly much longer than the sum of all time saved on the employ of this knowledge.

[blackcoder41]

what if the file is in a directory called
c:\my folder\kljlkjflvchfkjghuyruyftybmkjnbxjhiueygkjrhgkjh\oiutojlkjlj\file.exe

nice video, not everyone can type that fast. and you use shortcuts %windir%.
those are environment variables. system32 is also included in %path% that's why you can access cmd.exe from the start menu.

so if you really love textbase then install MS-Dos on your fast computer.. LOL. just kidding.

nice try =P

[chrisname]

Disch wrote:

I won't disagree that keyboard is faster than the mouse. In fact I prefer to use the keyboard whenever practical for that very reason.

Me too; I hate using the damn mouse where unnecessary. Some things force you to, even though the keyboard would be faster.

Assuming you know the exact name of every path in the diretory tree, have whatever cryptic commands you need (and any arguments they take) memorized, and don't mistype anything, then yes, you're right.

Well, there you go, then. I wouldn't say sizeof <file> is exactly cryptic though, would you? Anyway, console programs have usage messages for a reason... the same reason UNIX has man pages and everything.

Also, who boots explorer from the start menu? Don't you have shortcuts to common directories in the launcher on your taskbar? Do you at least have a cmd shortcut since you appreantly use it a lot? Or do you actually go to Run every time?

No, I'm on a laptop temporarily. On my other PC, on the rare occasion I use windows for anything except playing games, I have the taskbar at the top. I find it's faster there; one reason that could be is because the window controls are also at the top. The issue with that is that the windows gui is so fail that occasionally, programs manage to put themselves in stupid places such that you can't move them, and you can't access the window controls. You have to move the taskbar to one side and then move the window. The gui should not let programs do that.

Plus, when I get my PC back, I'll show you my panels in GNOME. Whenever I install an operating system that uses GNOME, I spend about half an hour organisng the panels to ultimately increase my productivity. In fact, I might even be able to find a screenshot I posted here before for you.

blackcoder41 wrote:

nice video, not everyone can type that fast. and you use shortcuts %windir%.

Yes; there's also %systemroot%, but for some reason, there's no expanding string for system32 itself. You'd expect there to be a %sysdir% or something. I could make one, but I cba.

system32 is also included in %path% that's why you can access cmd.exe from the start menu.

You might also notice that there's an icon to cmd.exe on my start menu. I would have thought the reason I used the text box was apparent: to make it a fair test...

[helios]

I think it's quicker to type "sizeof <file>" and read 2 lines of output than to go to a directory that could potentially contain thousands of files (not enough to fit on a scrollable terminal, let alone a vmode 3 screen), find the one you're looking for, and read it's size.

What about ls -l <filename>? Is that also too complicated for you?

1. click start
2. type "explorer" and hit enter
3. click the path bar
4. type C:\Windows\System32 and hit enter
5. find and right-click cmd.exe
6. left-click properties
faster than I can
1. click start
2. type "cmd" and hit enter
3. type "cd C:\Windows\System32" and hit enter
4. type "sizeof cmd.exe"

Well, yeah, it will take longer if you do it the wrong way.
1. Win+R
2. "c:\windows\system32"
3. ...

typing in Dvorak is faster than typing in Qwerty

That's a myth started by the vendor many years ago, IIRC. Proof by assertion at its finest.

[chrisname]

What about ls -l <filename>? Is that also too complicated for you?

Why are you all determined to make this basic program more pointless than it already is?

Well, yeah, it will take longer if you do it the wrong way.

Again, I would have thought the reason I did it like that was apparent. Besides, you could do
1. windows key + r
2. "cmd & cd %windir%\system32"
3. "sizeof cmd.exe"

It's still faster.

[helios]

Well, your question was "Why doesn't every OS have a program like this?" We're answering that question.