I've developed my hm command (pronounced "home")*, I've modified a Linux
kernel mouse driver* to support Microsoft Wireless Optical mice with tilt
wheel technology. I use emacs and extend it with LISP. I know my stuff.
And with this authority, I have to say that I see nothing wrong with Jeff
Relf's X.CPP.
Using macros is actually a good idea and is an advanced concept in many
programming languages. LISP is a programming language that idealizes the
macro. Relf's programming style is quite advanced, and his use of C++ to
create a language suited for the application is one trait that LISP
programmers are able to do with ease. LISP programmers actually look down
on C++ because it lacks the ability to become a new programming language
that fits the current application.
Relf has managed to use C/C++ in a LISP fashion. I commend him for it. As a
matter of fact, one of the C/C++ Users Journal's featured writers actually
showed how to, as Relf has done, use C++ in a more LISP like way. That
included MACROS and many LISP ideas. Relf is in the league of the likes of
Paul Graham, who modify the language to suite the program. That is truely
artful programming.
And who needs comments when the code says it all?
--
1. Do a groups.google search for the code to both my mouse driver
modification and my "hm" command.
From: Mike Cox
Subject: Re: I'm a C++ programmer, and Relf's X.CPP is good.
Date:
Message-ID: <2rjrdrF1bha1uU1@uni-berlin.de>
Stefaan A Eeckels wrote:
> On Fri, 24 Sep 2004 13:46:37 -0700
> Mike Cox <············@yahoo.com> wrote:
>
>> I've developed my hm command (pronounced "home")*, I've modified a Linux
>> kernel mouse driver* to support Microsoft Wireless Optical mice with
>> tilt wheel technology. I use emacs and extend it with LISP. I know my
>> stuff. And with this authority, I have to say that I see nothing wrong
>> with Jeff Relf's X.CPP.
>
> <snip drivel>
>
>> 1. Do a groups.google search for the code to both my mouse driver
>> modification and my "hm" command.
>
> I don't know why you wrote 'hm', as the 'cd' command without
> parameters will take you back to your home dir :-).
>
> But as you insist in positioning yourself as an expert, I had a
> look at your so-called C++ code, and, to be quite candid, it stinks,
> and it doesn't compile either.
>
> This is the thing I located:
>
> | /*
> | (c) 2004 Mike Cox. Released under the GNU GPL License.
> | email: ············@yahoo.com
> | web: www.geocities.com/mikecoxlinux/
> |
> | ****** Home Version 2 ******
> | The "hm" (shortened from home) command takes you to
> | your home directory if you've been wandering far and
> | don't want to type so much.
> |
> | Just type "hm" at the shell, and you're immediatly
> | transported to /home/yourusername/
>
>
>
You fool. The version I was at was version 3.0. The thread title is called
""hm" command posted without formattin errors." Type that in google
groups. But you don't have too since I'm going to post the code here.
Here is the full version:
/*
AUTHOR: Mike Cox.
EMAIL: ············@yahoo.com
WEB: www.geocities.com/mikecoxlinux/
COPYRIGHT: (C) 2004 Mike Cox. All Rights Reserved.
VERSION: Version 3.0
******** THE "hm" [pronounced "home"] COMMAND ********
LICENSE: "hm" is released under the GNU GPL License.
WARRANTY: This program is provided AS IS. There is NO
warranty for this software program. The Author
assumes NO responsiblity for the usablity of this
software. Use at your own risk.
FEATURES: 0: Takes the user to their home directory.
1: Allows user to store directories in 26 buffers.
2: Allows user to change to directories in those buffers.
3: Allows user to list contents of the current directory.
4: Allows user to list contents of directories in the 26 buffers.
5: Allows user to specify directory for hm to list the contents of.
EXAMPLES:
0: linux:/usr/local/# hm
1: linux:/usr/local/doc/# hm -s a
-or-
linux:/home/user# hm -s a /usr/local/share/doc/
2: linux:/home/user# hm -r a
3: linux:/home/user# hm -l
4: linux:/home/user# hm -l a
5: linux:/home/user# hm -l /usr/local/share/doc/
COMPILE: "hm" can be compiled using this command:
g++ -o hm hm.cpp
INSTALL: Move the "hm" program to:
/usr/local/bin/
*/
#include <iostream>
#include <pwd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <vector>
using std::vector;
void recall_path(int argc, char** argv);
void set_path(int argc, char** argv);
void write_path(char* hm_path, char hm_buf);
void list_contents(int argc, char** argv);
void go_home();
int main(int argc, char** argv)
{
if(argc > 1){
if(strcmp(argv[1], "-r") == 0){
recall_path(argc, argv);
}else if(strcmp(argv[1], "-s") == 0){ set_path(argc, argv);
}else if(strcmp(argv[1], "-l") == 0){ list_contents(argc, argv);
}else{
std::cout<<"Error: "<<argv[1];
std::cout<<" is not a supported option.\n";
}
}
//Going home.
else{
go_home();
} return 0;
}
void recall_path(int argc, char** argv)
{
/* Get the user .hm file. */
uid_t hm_usr;
struct passwd* hm_ps;
hm_usr = getuid();
hm_ps = getpwuid(hm_usr);
if(!hm_ps){
std::cout<<"Error: Set Path Failed.\n ";
exit(1);
}
char* hm_name = new char[strlen(hm_ps->pw_dir) + 5];
strcpy(hm_name, hm_ps->pw_dir);
strcat(hm_name,"/.hm");
/* Read file and find buffer. Execute corrosponding path*/
FILE* o;
o = fopen(hm_name,"r");
//please help. I'm stuck on how to do this. Windows has a better API.
// fseek();
fclose(o);
delete [] hm_name;
}
void set_path(int argc, char** argv)
{
/*
Makes sure the user has specified an alpha buffer.
Then writes the current directory or a user specified one to the buffer.
*/
if(argc < 3){
std::cout<<"Error: Need to specify a buffer. Lower case [a-z] are valid.
\n";
exit(1);
}
if(islower(argv[2][0])){
if(argc == 3){
write_path(get_current_dir_name(),argv[2][0]);
}else if(argv[3][0] == '/'){ write_path(argv[3], argv[2][0]);
}else{ std::cout<<"Error: Not a valid directory name.\n";
}
}else{
for(int i = 0; i < argc; ++i){
std::cout<<argv[i];
std::cout<<" ";
}
std::cout<<"Error: Need to specify a buffer. Lower case [a-z] are valid.
\n";
}
}
void write_path(char* hm_path, char hm_buf )
{
/*
The current POSIX way of getting the user's name and home directory.
cuserid() is deprecated. See glibc documentation at: http://www.gnu.org
*/
uid_t hm_usr;
struct passwd* hm_ps;
hm_usr = getuid();
hm_ps = getpwuid(hm_usr);
if(!hm_ps){
std::cout<<"Error: Set Path Failed.\n ";
exit(1);
}
char* hm_name = new char[strlen(hm_ps->pw_dir) + 5];
strcpy(hm_name, hm_ps->pw_dir);
strcat(hm_name,"/.hm");
FILE* o;
o =fopen(hm_name, "a");
/* Turn hm_buf into a string */
char b[2];
b[0] = hm_buf;
b[1] = '\0';
/* Put the buffer and path into the file. */
//there is a bug in that it doesn't check to see if buffer
//exists already. Ideas on a fix would be helpful. 2 or more
//same buffers are possible. :-(.
fputs(b, o);
fputs(" ", o);
fputs(hm_path, o);
fputs("\n", o);
/* close file and delete memory */
fclose(o);
delete [] hm_name;
}
void list_contents(int argc, char** argv)
{
/*
For right now, it just lists the current dir contents.
Soon, you will be able to list contents in buffer directories.
*/
system("ls -la");
}
void go_home()
{
uid_t hm_usr;
struct passwd* hm_ps;
hm_usr = getuid();
hm_ps = getpwuid(hm_usr);
if(!hm_ps){
std::cout<<"Error: Go Home Failed. \n ";
exit(1);
}
chdir(hm_ps->pw_dir);
execl(hm_ps->pw_shell,hm_ps->pw_shell,(const char*) NULL);
}
On Fri, 24 Sep 2004 17:06:53 -0700
Mike Cox <············@yahoo.com> wrote:
> Stefaan A Eeckels wrote:
>
> > On Fri, 24 Sep 2004 13:46:37 -0700
> > Mike Cox <············@yahoo.com> wrote:
> >
> >> I've developed my hm command (pronounced "home")*, I've modified a
> >> Linux kernel mouse driver* to support Microsoft Wireless Optical mice
> >>with tilt wheel technology. I use emacs and extend it with LISP. I
> >>know my stuff. And with this authority, I have to say that I see
> >>nothing wrong with Jeff Relf's X.CPP.
> >
> > <snip drivel>
> >
> >> 1. Do a groups.google search for the code to both my mouse driver
> >> modification and my "hm" command.
> >
> > I don't know why you wrote 'hm', as the 'cd' command without
> > parameters will take you back to your home dir :-).
> >
> > But as you insist in positioning yourself as an expert, I had a
> > look at your so-called C++ code, and, to be quite candid, it stinks,
> > and it doesn't compile either.
> >
> > This is the thing I located:
> >
> > | /*
> > | (c) 2004 Mike Cox. Released under the GNU GPL License.
> > | email: ············@yahoo.com
> > | web: www.geocities.com/mikecoxlinux/
> > |
> > | ****** Home Version 2 ******
> > | The "hm" (shortened from home) command takes you to
> > | your home directory if you've been wandering far and
> > | don't want to type so much.
> > |
> > | Just type "hm" at the shell, and you're immediatly
> > | transported to /home/yourusername/
> >
> >
> >
> The version I was at was version 3.0.
If you don't want old versions to be found, then post accurate
references. This was the first result that came up, your home
page is empty, and I cannot be expected to know what version
your program is at.
> The thread title is
> called""hm" command posted without formattin errors." Type that in
> google groups. But you don't have too since I'm going to post the code
> here. Here is the full version:
It still doesn't compile:
blinky~/Stuff[180] g++ -o hm home.cpp
home.cpp: In function `void recall_path(int, char **)':
home.cpp:90: implicit declaration of function `int fopen(...)'
home.cpp:90: assignment to `FILE *' from `int' lacks a cast
home.cpp:93: implicit declaration of function `int fclose(...)'
That's normal seeing you forgot to include stdio.h
home.cpp: In function `void set_path(int, char **)':
home.cpp:108: implicit declaration of function `int islower(...)'
That's normal because you forgot to include ctype.h
home.cpp:110: implicit declaration of function `int
get_current_dir_name(...)'
That's normal because get_current_dir_name is not prototyped unless
you define __GNU_SOURCE (portable code, this).
home.cpp:110: passing `int' to argument 1 of `write_path(char *, char)'
lacks a cast home.cpp: In function `void write_path(char *, char)':
home.cpp:146: assignment to `FILE *' from `int' lacks a cast
home.cpp:155: implicit declaration of function `int fputs(...)'
Let's have a look if you've managed to come up with something
else than forks and pipes...
> void go_home()
> {
>
> uid_t hm_usr;
> struct passwd* hm_ps;
>
> hm_usr = getuid();
> hm_ps = getpwuid(hm_usr);
>
> if(!hm_ps){
> std::cout<<"Error: Go Home Failed. \n ";
> exit(1);
> }
> chdir(hm_ps->pw_dir);
> execl(hm_ps->pw_shell,hm_ps->pw_shell,(const char*) NULL);
>
> }
And what do you think this does? Hint - it executes a new
copy of the shell, it does not change the current directory
in the user's login shell.
> if(islower(argv[2][0])){
> if(argc == 3){
> write_path(get_current_dir_name(),argv[2][0]);
> }else if(argv[3][0] == '/'){ write_path(argv[3], argv[2][0]);
> }else{ std::cout<<"Error: Not a valid directory name.\n";
> }
> ...
> void write_path(char* hm_path, char hm_buf )
> {
> ....
> /* Turn hm_buf into a string */
> char b[2];
> b[0] = hm_buf;
> b[1] = '\0';
How stupid can one be? Why do you take a character from a
string only to turn into a string again? Just pass the original
string.
> FILE* o;
> o =fopen(hm_name, "a");
> /* Turn hm_buf into a string */
> char b[2];
> b[0] = hm_buf;
> b[1] = '\0';
> /* Put the buffer and path into the file. */
> //there is a bug in that it doesn't check to see if buffer
> //exists already. Ideas on a fix would be helpful. 2 or more
> //same buffers are possible. :-(.
> fputs(b, o);
> fputs(" ", o);
> fputs(hm_path, o);
> fputs("\n", o);
> /* close file and delete memory */
> fclose(o);
You didn't notice that not only does this not check that the
buffer is already in the file, it blightly overwrites
the file starting at byte #0.
Don't bother to fix this program, just toss it and buy
a book. I suggest "Beginning Linux Programming" from
Wrox Press. Work through it slowly, and there might be
some hope left for you.
I decided to make your cruft compile (by adding the required
#include files and a #define _GNU_SOURCE), to show you what it
does:
blinky~/Stuff[191] g++ -o hm home.cpp
blinky~/Stuff[192] ./hm
blinky~[101] exit
exit
blinky~/Stuff[193]
See? It created a new instance of the shell. If you use this
command several times to so-called go to your home directory,
you'll end up with umpteen instances of your shell.
You cannot change to your home directory through an external
command. It simply cannot be done, just forget it. As I said
in my previous post, "cd" takes you back to your home
directory. If you don't like the name, just alias it to hm:
blinky~/Stuff[193] alias hm cd
blinky~/Stuff[194] hm
blinky~[195] pwd
/home/sae
blinky~[196]
Now how difficult was that?
You, sir, are NOT a C++ programmer. The paragraph below is
so ridiculous it's almost sad:
> I've developed my hm command (pronounced "home")*, I've modified a Linux
> kernel mouse driver* to support Microsoft Wireless Optical mice with
> tilt wheel technology. I use emacs and extend it with LISP. I know my
> stuff. And with this authority, I have to say that I see nothing wrong
> with Jeff Relf's X.CPP.
You don't know your stuff, and worse, you don't know you don't
know it. And everything is wrong with Jeff Relf's X.CPP. It's even
worse than your code (at least yours has a semblance of formatting and
comments).
Now please leave comp.unix.programmer alone.
--
Stefaan
--
"What is stated clearly conceives easily." -- Inspired sales droid
Mike Cox <············@yahoo.com> wrote in message news:<···············@uni-berlin.de>...
> Stefaan A Eeckels wrote:
>
> > On Fri, 24 Sep 2004 13:46:37 -0700
> > Mike Cox <············@yahoo.com> wrote:
> >
> >> I've developed my hm command (pronounced "home")*, I've modified a Linux
[ snip ]
> You fool. The version I was at was version 3.0. The thread title is called
> ""hm" command posted without formattin errors." Type that in google
> groups. But you don't have too since I'm going to post the code here.
> Here is the full version:
>
> /*
> AUTHOR: Mike Cox.
> EMAIL: ············@yahoo.com
Everything in this program can be done with a few easy functions
loaded into your shell when you log in. These functions can maintain
persistent data in the .hm file in the home directory just like your
awkward C program does. The same syntax can be used, including all the
options.
The GNU Bourne-Again Shell (bash) has some functions for maintaining a
stack of directories, imitated from the C shell. Look at the commands
pushd, popd and dirs. Together with cd, these cover most of the
functionality of hm, other than persistence of the directory stack.
> void go_home()
You might want to take this advice.
From: Måns Rullgård
Subject: Re: I'm a C++ programmer, and Relf's X.CPP is good.
Date:
Message-ID: <yw1xzn3e3z50.fsf@mru.ath.cx>
···@ashi.footprints.net (Kaz Kylheku) writes:
> Mike Cox <············@yahoo.com> wrote in message news:<···············@uni-berlin.de>...
>> Stefaan A Eeckels wrote:
>>
>> > On Fri, 24 Sep 2004 13:46:37 -0700
>> > Mike Cox <············@yahoo.com> wrote:
>> >
>> >> I've developed my hm command (pronounced "home")*, I've modified a Linux
>
> [ snip ]
>
>> You fool. The version I was at was version 3.0. The thread title is called
>> ""hm" command posted without formattin errors." Type that in google
>> groups. But you don't have too since I'm going to post the code here.
>> Here is the full version:
>>
>> /*
>> AUTHOR: Mike Cox.
>> EMAIL: ············@yahoo.com
>
> Everything in this program can be done with a few easy functions
> loaded into your shell when you log in. These functions can maintain
> persistent data in the .hm file in the home directory just like your
> awkward C program does. The same syntax can be used, including all the
> options.
I posted those shell functions here, and they totaled about a dozed
lines.
> The GNU Bourne-Again Shell (bash) has some functions for maintaining a
> stack of directories, imitated from the C shell. Look at the commands
> pushd, popd and dirs. Together with cd, these cover most of the
> functionality of hm, other than persistence of the directory stack.
>
>> void go_home()
>
> You might want to take this advice.
raise(9)
--
M�ns Rullg�rd
···@mru.ath.cx
Hi Mike Cox,
Re: My X.CPP code,
http://www.Cotse.NET/users/jeffrelf/X.CPP ,
You wrote: <<
Relf is in the league of the likes of Paul Graham,
who modify the language to suite the program.
That is truly artful programming. >>
From http://en.wikipedia.org/wiki/Paul_Graham,
I see that Paul created Viaweb in 1995, <<
whose flagship product
( written largely in Common Lisp )
let users make their own Internet stores.
In the summer of 1998 he sold Viaweb to Yahoo!,
where it became Yahoo! Store. >>
X.CPP is primarily vaporware an only used by me,
so I don't think I stack up well when compared to Paul.
But I do thank you for your kind words.
Please don't change the titles of MY threads please. I have a hard time
following them in emacs if the titles change constantly.
From: Floyd L. Davidson
Subject: Mike Cox is a Troll [was Re: Paul Graham vs. Jeff Relf ?]
Date:
Message-ID: <87wtyjdskt.fld_-_@barrow.com>
Mike Cox <············@yahoo.com> wrote:
>Please don't change the titles of MY threads please. I have a hard time
>following them in emacs if the titles change constantly.
You don't own any threads.
--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) ·····@barrow.com
Hi Mike Cox,
You asked: <<
Please don't change the titles of MY threads please.
I have a hard time following them in emacs
if the titles change constantly. >>
Turn off: " Create new threads on title changes ".
Otherwise... suffer.
Error BR-549: MS DRM 1.0 rejects the following post from Jeff Relf:
> Hi Mike Cox,
>
> Re: My X.CPP code,
> http://www.Cotse.NET/users/jeffrelf/X.CPP ,
>
> Relf is in the league of the likes of Paul Graham,
> who modify the language to suite the program.
> That is truly artful programming. >>
Tag-team trolling!
--
[X] Check here to always trust content from Lin�nut
On Fri, 24 Sep 2004, Jeff Relf wrote:
> But I do thank you for your kind words.
Don't feel too greatful - Mike Cox is a known and frequent troller.
(No, I don't mean that disparagingly towards you!)
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
[Reposted to comp.unix.programmer, comp.lang.lisp]
On Fri, 24 Sep 2004 13:46:37 -0700
Mike Cox <············@yahoo.com> wrote:
> I've developed my hm command (pronounced "home")*, I've modified a Linux
> kernel mouse driver* to support Microsoft Wireless Optical mice with
> tilt wheel technology. I use emacs and extend it with LISP. I know my
> stuff. And with this authority, I have to say that I see nothing wrong
> with Jeff Relf's X.CPP.
<snip drivel>
> 1. Do a groups.google search for the code to both my mouse driver
> modification and my "hm" command.
I don't know why you wrote 'hm', as the 'cd' command without
parameters will take you back to your home dir :-).
But as you insist in positioning yourself as an expert, I had a
look at your so-called C++ code, and, to be quite candid, it stinks,
and it doesn't compile either.
This is the thing I located:
| /*
| (c) 2004 Mike Cox. Released under the GNU GPL License.
| email: ············@yahoo.com
| web: www.geocities.com/mikecoxlinux/
|
| ****** Home Version 2 ******
| The "hm" (shortened from home) command takes you to
| your home directory if you've been wandering far and
| don't want to type so much.
|
| Just type "hm" at the shell, and you're immediatly
| transported to /home/yourusername/
First, this isn't C++. It's 'C' with a couple C++ cout statements,
and I can see why you like X.CPP. Second, you assume that the home
directory of "root" is "/root", and the home directory of
all other users is "/home". That's an utterly unwarranted
assumption, and worse, there's an API to get a user's home
directory from the system. You also use the user name instead
of the UID - root doesn't need to be called root, Einstein.
Now to the real shocker - your command doesn't work. Worse, it
cannot work, as you're trying to change the state of the shell
through an external command. There's no way to achieve what you
want to do through a process (which is why cd is a shell built-in,
and not a command).
Oh well, it doesn't compile because glibc is NOT automatically
there, contrary to what you believe:
blinky~/Stuff[133] make hm
g++ hm.cpp -o hm
hm.cpp: In function `void set_path(int, char **)':
hm.cpp:33: implicit declaration of function `int cuserid(...)'
hm.cpp:48: implicit declaration of function `int strcat(...)'
hm.cpp: In function `void go_home()':
hm.cpp:69: `pid_t' undeclared (first use this function)
hm.cpp:69: (Each undeclared identifier is reported only once
hm.cpp:69: for each function it appears in.)
hm.cpp:69: parse error before `;'
hm.cpp:70: `parent' undeclared (first use this function)
hm.cpp:70: implicit declaration of function `int getppid(...)'
hm.cpp:71: implicit declaration of function `int fork(...)'
make: *** [hm] Error 1
blinky~/Stuff[134] g++ -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
As you can't be bothered to read manuals, you didn't see
the following comment in the cuserid manpage:
Nobody knows precisely what cuserid() does - avoid it in
portable programs - avoid it altogether - use getp
wuid(geteuid()) instead, if that is what you meant. DO
NOT USE cuserid().
But as your program doesn't compile, it shouldn't be too
bothersome. I added a couple of #include statements, and
a prototype for cuserid, but then the linker threw up:
blinky~/Stuff[152] cc hm.cpp -o hm
/var/tmp/ccPx3GPo.o: In function `main':
/var/tmp/ccPx3GPo.o(.text+0x85): undefined reference to `cout'
/var/tmp/ccPx3GPo.o(.text+0x8a): undefined reference to `ostream::operator<<(char const *)'
/var/tmp/ccPx3GPo.o(.text+0x9a): undefined reference to `cout'
/var/tmp/ccPx3GPo.o(.text+0x9f): undefined reference to `ostream::operator<<(char const *)'
/var/tmp/ccPx3GPo.o: In function `set_path(int, char **)':
/var/tmp/ccPx3GPo.o(.text+0xd9): undefined reference to `cuserid(char *)'
/var/tmp/ccPx3GPo.o: In function `recall_path(int, char **)':
/var/tmp/ccPx3GPo.o(.text+0x2e7): undefined reference to `cout'
/var/tmp/ccPx3GPo.o(.text+0x2ec): undefined reference to `ostream::operator<<(char const *)'
/var/tmp/ccPx3GPo.o: In function `go_home(void)':
/var/tmp/ccPx3GPo.o(.text+0x308): undefined reference to `cout'
/var/tmp/ccPx3GPo.o(.text+0x30d): undefined reference to `ostream::operator<<(char const *)'
/var/tmp/ccPx3GPo.o(.text+0x342): undefined reference to `cuserid(char *)'
collect2: ld returned 1 exit status
Which isn't a surprise, because your build instructions
forget to link the standard C++ library. Easy to fix, that
one:
blinky~/Stuff[160] g++ hm.cpp -o hm -lstdc++
/var/tmp/ccXKFlHc.o: In function `set_path(int, char **)':
/var/tmp/ccXKFlHc.o(.text+0xd9): undefined reference to `cuserid(char *)'
/var/tmp/ccXKFlHc.o: In function `go_home(void)':
/var/tmp/ccXKFlHc.o(.text+0x342): undefined reference to `cuserid(char *)'
collect2: ld returned 1 exit status
By now I'm through debugging your code (which you seem to expect
as it's GPLed), and I decide to plug in my username to demonstrate
that it doesn't work (it's past one o'clock a.m. here).
That allows me to notice the following:
char* name = new char;
Not good, this. You need at least L_cuserid characters. Oh well,
it's in keeping with the quality of the program, to have buffer
overlows.
Finally, I get a clean compile and link:
blinky~/Stuff[170] g++ hm.cpp -o hm -lstdc++
blinky~/Stuff[171] ./hm
Going home..
blinky~/Stuff[172] pwd
/home/sae/Stuff
But alas, executing hm doesn't take me home... At least, it
doesn't dump a core :-). What did you expect from the
following anyway?
void go_home()
{
std::cout<<"Going home..\n";
pid_t parent;
parent = getppid();
parent = fork();
char* name = new char;
cuserid(name);
if(strcmp(name, "root")==0){
FILE* bong_pipe;
bong_pipe = popen("cd /root","w");
pclose(bong_pipe);
}else{
FILE* bong_pipe;
char* command = new char[strlen(name) + 10 ];
strcpy(command,"cd /home/");
strcat(command,name);
bong_pipe = popen(command, "w");
delete [] command;
} delete [] name;
}
Did you really think that a pipe would talk to your
current shell? What on earth is the "fork()" supposed
to do? Create two processes that do nothing?
This program is a cruel joke. Is this what should qualify
you as someone who "knows his stuff"? If so, I can affirm
with certainty that you know diddly squat, and don't even
have the sense to know you know nothing.
Someone who puts crap like this on USENET should refrain
from making any programming related comments.
--
Stefaan (writing in 'C' on Unix since 1980)
--
"What is stated clearly conceives easily." -- Inspired sales droid
--
Stefaan
--
"What is stated clearly conceives easily." -- Inspired sales droid
From: Kalle Olavi Niemitalo
Subject: Re: I'm a C++ programmer, and Relf's X.CPP is good.
Date:
Message-ID: <876562ex9c.fsf@Astalo.kon.iki.fi>
Stefaan A Eeckels <·····@DELETEMEecc.lu> writes:
> Now to the real shocker - your command doesn't work. Worse, it
> cannot work, as you're trying to change the state of the shell
> through an external command.
IIRC, GNU/Hurd has a command that changes the working directory
of another process, or opens or closes files in it. It works by
sending a message to a thread that glibc starts automatically.
On other operating systems, you can instead attach a debugger to
the process and force a call to chdir(). I once did that to Lynx
on Solaris, to get all downloaded files easily to the same directory.
On Sat, 25 Sep 2004 08:24:47 +0300
Kalle Olavi Niemitalo <···@iki.fi> wrote:
> Stefaan A Eeckels <·····@DELETEMEecc.lu> writes:
>
> > Now to the real shocker - your command doesn't work. Worse, it
> > cannot work, as you're trying to change the state of the shell
> > through an external command.
>
> IIRC, GNU/Hurd has a command that changes the working directory
> of another process, or opens or closes files in it. It works by
> sending a message to a thread that glibc starts automatically.
This is comp.UNIX.programmer, and there is no way you can
modify a parent process' state through a unilateral action
in of the child. Obviously, if a program provides a mechanism
it can be done. This isn't the case here.
> On other operating systems, you can instead attach a debugger to
> the process and force a call to chdir(). I once did that to Lynx
> on Solaris, to get all downloaded files easily to the same directory.
And Java and Tcl will let you attach a console to a running
interpreter and interact with it.
Still, the "hm" program remains like the ultimate excercise
in futile programming. Hey, that's an idea. There's literate
programming, extreme programming, agile programming etc., so
obviously there's a need for futile programming, and Mike Cox
can be the Ed Yourdon of futile programming.
This reminds me of a friend called Mike Cox (not this one) who
was a building contractor, and called his company "Cox Erections".
Take care,
--
Stefaan
--
"What is stated clearly conceives easily." -- Inspired sales droid