Re: ftp transfers
Ivan van der Merwe wrote: Hi I need to do fequent ftp downloads. I would like to put this in the crontab if possible. In windows you can specify a file containing all the files that you want downloaded. Can I do the same on Unix Of course you can: ftp some.server.com EOF username password cd /some/directory get file1 get file2 EOF This is called a 'here is' document. But really it's much easier to just use fetch. See the fetch(1) man page. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: nfs v2
Wow! your message was educational and refreshing. somebody actualy knows! i will keep it for reference. as to your requests: since from all my experiments i've poluted too many file systems, i will start from scratch and send you a full report asap. basicaly, if i understand your explanation, i will always have problems with mknod and v2/v3. so i see only one solution: only use v3 for nfs-root clients, correct? (i mean v3, since mount and automounters alike, unless specificaly requesting v2, will default to v3). danny Daniel Braniss e-mail: [EMAIL PROTECTED] Manager of Computing Facilities phone: +972 2 658 4385 School of Computer Science and Engineering Fax:+972 2 561 7723 The Hebrew University Jerusalem Edmond Safra Campus, Givat Ram, Israel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kld/cdev won't compile
I'm currently running 4.1-RELEASE and can't compile the code in: /usr/share/examples/kld/cdev/module The command "make" returns the following to stderr: cdevmod.c:142: macro `DEV_MODULE' used with too many (6) args cdevmod.c:84: `nostop' undeclared here (not in a function) cdevmod.c:84: initializer element is not constant cdevmod.c:84: (near initialization for `my_devsw.d_poll') cdevmod.c:85: `noreset' undeclared here (not in a function) cdevmod.c:85: initializer element is not constant cdevmod.c:85: (near initialization for `my_devsw.d_mmap') cdevmod.c:86: `nodevtotty' undeclared here (not in a function) cdevmod.c:86: initializer element is not constant cdevmod.c:86: (near initialization for `my_devsw.d_strategy') cdevmod.c:87: warning: initialization from incompatible pointer type cdevmod.c:88: warning: initialization makes integer from pointer without a cast cdevmod.c:89: warning: initialization from incompatible pointer type cdevmod.c:90: warning: initialization from incompatible pointer type cdevmod.c:91: `noparms' undeclared here (not in a function) cdevmod.c:91: initializer element is not constant cdevmod.c:91: (near initialization for `my_devsw.d_flags') cdevmod.c:93: warning: excess elements in struct initializer cdevmod.c:93: warning: (near initialization for `my_devsw') cdevmod.c:94: warning: excess elements in struct initializer cdevmod.c:94: warning: (near initialization for `my_devsw') cdevmod.c:95: warning: excess elements in struct initializer cdevmod.c:95: warning: (near initialization for `my_devsw') cdevmod.c:96: warning: excess elements in struct initializer cdevmod.c:96: warning: (near initialization for `my_devsw') cdevmod.c:98: warning: excess elements in struct initializer cdevmod.c:98: warning: (near initialization for `my_devsw') cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:78: warning: `my_devsw' defined but not used cdevmod.c:113: warning: `cdev_load' defined but not used Also, "grep include cdevmod.c" returns: #include sys/param.h #include sys/systm.h #include sys/kernel.h #include sys/module.h #include sys/conf.h #include "cdev.h" but none of those include files contain "nostop", "noreset", etc. As for DEV_MODULES, the code in /usr/src/sys only uses 3 args, so I'm stumped on that one. Suggestions to solve these problems would be most appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kld/cdev won't compile
Marc, Yes... This is known. I know I sent in a send-pr awhile back.. but it's not a big priority, in my opinion. HOWEVER, you can see working examples and a tutorial at: http://www.subterrain.net/~awr/KLD-Tutorial/intro.html This will also be in daemonnews on the 1st. Andrew On Fri, 29 Sep 2000, Marc Tardif wrote: I'm currently running 4.1-RELEASE and can't compile the code in: /usr/share/examples/kld/cdev/module The command "make" returns the following to stderr: cdevmod.c:142: macro `DEV_MODULE' used with too many (6) args cdevmod.c:84: `nostop' undeclared here (not in a function) cdevmod.c:84: initializer element is not constant cdevmod.c:84: (near initialization for `my_devsw.d_poll') cdevmod.c:85: `noreset' undeclared here (not in a function) cdevmod.c:85: initializer element is not constant cdevmod.c:85: (near initialization for `my_devsw.d_mmap') cdevmod.c:86: `nodevtotty' undeclared here (not in a function) cdevmod.c:86: initializer element is not constant cdevmod.c:86: (near initialization for `my_devsw.d_strategy') cdevmod.c:87: warning: initialization from incompatible pointer type cdevmod.c:88: warning: initialization makes integer from pointer without a cast cdevmod.c:89: warning: initialization from incompatible pointer type cdevmod.c:90: warning: initialization from incompatible pointer type cdevmod.c:91: `noparms' undeclared here (not in a function) cdevmod.c:91: initializer element is not constant cdevmod.c:91: (near initialization for `my_devsw.d_flags') cdevmod.c:93: warning: excess elements in struct initializer cdevmod.c:93: warning: (near initialization for `my_devsw') cdevmod.c:94: warning: excess elements in struct initializer cdevmod.c:94: warning: (near initialization for `my_devsw') cdevmod.c:95: warning: excess elements in struct initializer cdevmod.c:95: warning: (near initialization for `my_devsw') cdevmod.c:96: warning: excess elements in struct initializer cdevmod.c:96: warning: (near initialization for `my_devsw') cdevmod.c:98: warning: excess elements in struct initializer cdevmod.c:98: warning: (near initialization for `my_devsw') cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:78: warning: `my_devsw' defined but not used cdevmod.c:113: warning: `cdev_load' defined but not used Also, "grep include cdevmod.c" returns: #include sys/param.h #include sys/systm.h #include sys/kernel.h #include sys/module.h #include sys/conf.h #include "cdev.h" but none of those include files contain "nostop", "noreset", etc. As for DEV_MODULES, the code in /usr/src/sys only uses 3 args, so I'm stumped on that one. Suggestions to solve these problems would be most appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ptrace question
Below I have provided a sample program to demonstrate the problem I am
having. Basically, when I ptrace() an ncurses program (such has ncftp
2.4.3), I cannot do a PT_CONTINUE followed by a PT_STEP normally.
To demonstrate, the program gets ncftp ready for ptracing and then calls
ptrace() with PT_CONTINUE on it. This works perfectly, and if the program
receives a signal, such as a SIGINT from a CTRL-C, I then attempt to use
ptrace() with PT_STEP, to single-step the next instruction. This is where
it fails.
The wait() call after the ptrace(PT_STEP) call does not return until you
hit the ENTER key, and I cannot figure out why. The first wait() call
after the ptrace(PT_CONTINUE) returns normally, but when I use it after
the singlestep call, it will not return normally unless I hit a key.
As a side note, if I use ptrace(PT_CONTINUE) a second time (instead of
PT_STEP), the wait() call will return normally without having to hit a
key.
Also, if I run a non-ncurses program through this same procedure, the
wait() after the ptrace(PT_STEP) operates normally. I can only reproduce
this problem under ncurses programs like ncftp v2.4.3 - but I did use
tcgetattr() and tcsetattr() to reset the terminal settings, so I don't
know why ncurses would be affecting it. I also tried putting the terminal
into "raw" mode right before calling ptrace(PT_CONTINUE), but got the same
results, so I'm not sure if this is a raw/cooked mode issue..
If anyone knows what the problem could be, please let me know!
Cut here
/*
* The goal of this program is to run an ncurses program normally
* until a signal is caught, and then try to singlestep one
* instruction. It should demonstrate that the wait() call after
* the ptrace() singlestep call does not return as it should -
* you need to hit the ENTER key for the wait() call to return.
*
* Compile: gcc -o ptest ptest.c
*
* Run: ./ptest, hit ^C and you will see that you must hit
* a keystroke to get it to continue past the singlestep.
*/
#include stdio.h
#include sys/types.h
#include sys/ptrace.h
#include errno.h
#include sys/wait.h
#include signal.h
#include termios.h
#include unistd.h
/*
* Location of an ncurses program (NcFTP v2.x.x)
*/
char filename[] = "/usr/local/bin/ncftp2";
int
main()
{
int pid; /* child pid */
int waitval;
int sig;
struct termios SavedAttributes;
signal(SIGINT, SIG_IGN);
pid = fork();
switch (pid)
{
case -1:
{
perror("fork");
break;
}
/*
* Child
*/
case 0:
{
/*
* Allow parent to trace this child process
*/
ptrace(PT_TRACE_ME, 0, 0, 0);
/*
* Execute program to be debugged and cause child to
* send a signal to parent, so the parent can switch
* to PT_STEP
*/
execl(filename, filename, NULL);
break;
}
/*
* Parent
*/
default:
{
/*
* Wait for child to stop (execl)
*/
wait(waitval);
/* save attributes */
tcgetattr(STDIN_FILENO, SavedAttributes);
if (ptrace(PT_CONTINUE, pid, (caddr_t) 1, 0) != 0)
perror("ptrace");
wait(waitval);
/* restore attributes */
tcsetattr(STDIN_FILENO, TCSANOW, SavedAttributes);
fprintf(stderr, "\nwaitval1 = %d\n", waitval);
if (WIFSTOPPED(waitval))
{
sig = WSTOPSIG(waitval);
fprintf(stderr, "signal = %d\n", sig);
/*
* OK, they did the CONTROL-C, now try singlestepping the
* next instruction.
*/
fprintf(stderr, "SINGLESTEPPING - here is where you have to hit ENTER but
shouldn't need to\n");
if (ptrace(PT_STEP, pid, (caddr_t) 1, 0) != 0)
perror("ptrace");
/*
* Here is where you have to hit a key to get wait() to
* return???
*/
wait(waitval);
tcsetattr(STDIN_FILENO, TCSANOW, SavedAttributes);
fprintf(stderr, "DONE SINGLESTEP, waitval2 = %d\n", waitval);
}
}
}
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
finding source to functions
How can I find the source to specific functions in /usr/src/sys? I tried running ctags (find /usr/src/sys/ -type f -print | xargs ctags -w), but it dumps core because it can't accept so many args. I then tried creating a tags file for each subdirectory like so: for i in /usr/src/sys/ do if test -d $i then cd $i find ./ -type f -print | xargs ctags -w cd .. fi done But that didn't work either. Any suggestions to make browsing the source code easier? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing to disk
On Thu, 28 Sep 2000, Marc Tardif wrote: What is the quickest way of writing large amounts of data to disk? Sequentially. Disks run an order of magnitude faster if they have sequential data. Don't get too fancy with the ordering since the disk driver will just reorder it for you. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding source to functions
Marc Tardif wrote: How can I find the source to specific functions in /usr/src/sys? I tried running ctags (find /usr/src/sys/ -type f -print | xargs ctags -w), but it dumps core because it can't accept so many args. I then tried creating a tags file for each subdirectory like so: for i in /usr/src/sys/ do if test -d $i then cd $i find ./ -type f -print | xargs ctags -w cd .. fi done But that didn't work either. Any suggestions to make browsing the source code easier? There is glimpse in the ports tree (/usr/ports/textproc/glimpse), which can create a very efficient index for lots of text files (like source files) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding source to functions
Out of da blue Marc Tardif aka ([EMAIL PROTECTED]) said: How can I find the source to specific functions in /usr/src/sys? I tried running ctags (find /usr/src/sys/ -type f -print | xargs ctags -w), but it dumps core because it can't accept so many args. I then tried creating a tags file for each subdirectory like so: for i in /usr/src/sys/ do if test -d $i then cd $i find ./ -type f -print | xargs ctags -w cd .. fi done But that didn't work either. Any suggestions to make browsing the source code easier? There's also cscope and cbrowser in the ports under /usr/ports/devel ... #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: finding source to functions
* Marc Tardif [EMAIL PROTECTED] [000929 13:37] wrote: How can I find the source to specific functions in /usr/src/sys? I tried running ctags (find /usr/src/sys/ -type f -print | xargs ctags -w), but it dumps core because it can't accept so many args. I then tried creating a tags file for each subdirectory like so: for i in /usr/src/sys/ do if test -d $i then cd $i find ./ -type f -print | xargs ctags -w cd .. fi done But that didn't work either. Any suggestions to make browsing the source code easier? Sorta lame but: cd /usr/src/sys grep ^function */* works for me. of course there's a bunch of stuff in ports/textproc and devel that may also help. cscope and glimpse are nice. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing to disk
On Fri, 29 Sep 2000, Doug White wrote: On Thu, 28 Sep 2000, Marc Tardif wrote: What is the quickest way of writing large amounts of data to disk? Sequentially. Disks run an order of magnitude faster if they have sequential data. Don't get too fancy with the ordering since the disk driver will just reorder it for you. Also, lots of disks no longer seem to write individual sectors, but instead read/write whole tracks at a time. (and then the whole sector thing becomes moot) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stuck on MD5 passwd's, host to revert to DES
On Thu, 28 Sep 2000, Jim Mercer wrote: On Thu, Sep 28, 2000 at 06:14:07PM -0700, Kris Kennaway wrote: Set the value of the passwd_format login capability to "des" in /etc/login.conf. Brian Feldman neglected to document or mention this in the release notes at all, as far as I can tell. No cookie! Please fix this ASAP, Brian. I didn't document it in login.conf(5) -- that was an oversight. I'll add that in a bit (soon). I documented it in login_cap(3), so the programmers know about it but not the sysadmins :( so, is the intention to have FreeBSD default to md5? Yes. It's the more secure alternative and is quite suitable for most users. All the rest of you need to do is add the 'des' login capability in the default class. the reason i ask, is that if people cvsup without seeing or noticing this, they may not realize until too late that the new passwords are md5. anyone using nis with non-freebsd systems might get really upset. It should have been documented. It still can be :-) Agreed. It will work by default if FreeBSD systems are doing the yppasswdd, otherwise you'll probably get locked out of changing your password (because the remote yppasswdd must verify your old passwd, but then the new password probably won't have the same kinds of checks against it). Actually, you'd probably not be able to log in. This just needs to be documented; a FreeBSD system previously had to be manually set to use the DES libcrypt, but it would default the other way if the "secure" distribution was installed. Now it just needs a different change, and a bit of an easier one. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: nfs v2
On Fri, Sep 29, 2000 at 10:47:24AM +0300, Danny Braniss wrote: basicaly, if i understand your explanation, i will always have problems with mknod and v2/v3. Yes, mknod done with V3 will, unless your server treats special file major/minor device numbers the way FreeBSD does, probably create a special file that FreeBSD won't see as having the right major/minor device number. so i see only one solution: only use v3 for nfs-root clients, correct? That's probably the only solution that's guaranteed to work; given that FreeBSD's minor device number isn't stored in the lower N bits of the dev_t, I could see a V3 server, when it constructs a dev_t from the major and minor sent over the wire in a V3 MKNOD, overlapping bits from the major and minor device, causing information to be lost. Just in case there are servers that don't do V3, however, I'd try V3 and, if the server rejects the V3 request with PROG_MISMATCH, try V2 (and do a similar fallback with mount). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
