Search results

I know HFS+ can handle long filename; I'm guessing UFS can as well. Which filesystem are you using as the target when doing the tar? As a test, $ ls play.tar $ tar xvf play.tar this is an even longer filename which defintely goes past 31 characters $ ls play.tar this is an even...

I'm guessing you're extracting the tarball with StuffIt Expander? I notice it does have a problem with filenames of length > 31 characters; since it's a Carbon app, it can't handle really long names. The only way I can think of is using the tar command in a Terminal window, tar xvf ballof.tar

Getting a specific date means having a quick look at man strftime which is where the formats are documented; if your birthday is April first, you could do something like set today = `date '+%m%d'` if( $today == '0401' ) then banner happy birthday endif just be sure to use a...

Add this to your .tcshrc: set hour = `date '+%H'` if( $hour < 12 ) then echo "Good morning" else if( $hour < 18 ) then echo "Good afternoon" else if( $hour < 20 ) then echo "Good evening" else echo "Good night" endif Season to taste.

If it's the only entry in that crontab, then crontab -r removes the whole thing; if, however, there's other entries, crontab -e will bring the entire table in vi, and you can edit there.

Your or root's personal crontab perhaps? $ crontab -l $ sudo crontab -l It's not from /etc/[daily|weekly|monthly] since those kick off at times other than 12:01 (unless you've changed it in /etc/crontab).

If you mean the kern.securelevel sysctl option, it is present: $ sysctl -a |grep kern.secure kern.securelevel = 1 The big question is whether or not the kernel actually uses this; as shown above, mine is currently 1, but I can't find where it is set (on my OpenBSD machine, it's set in...

This is an issue with a tcsh logout script; a workaround has been found, look for kdestroy near the bottom of that thread.

That should be a capital N ssh-keygen -N '' Use man ssh-keygen to see all the options.

This should be as easy as ssh -L 10143:univserver:143 user@univserver This will forward any connections to your machines' port 10143 through ssh over to univserver's 143. Then you just tell your mail program to connect via IMAP to localhost:10143 .

Be sure not to remove them, just move them aside while you build OpenSSH, as you do need to put them back afterwards (for example, I have a /usr/lib/holdlib directory where I place them); there may be some binaries beyond the Apple-installed OpenSSH and OpenSSL which depend on them.

No problem here with 3.0.2p1 (ssh works fine, and ssh-keygen worked when I just tested it); I build it against OpenSSL 0.9.6c which I also built. In order to do this, I had to first move /usr/lib/libcrypt* and /usr/lib/libssl* out of /usr/lib, otherwise building OpenSSH will pick those up...

Apple recently posted a TIL on this exact issue.

0.0.0.0 is simply a way of saying all IP's. This way, it listens on 127.0.0.1, your normal IP, and any other. If it binds to a specific IP, then it binds to that IP only, and wouldn't appear on the others. For security reasons, some daemons bind only to 127.0.0.1 so they can provide local...

The script /System/Library/SystemConfiguration/Kicker.bundle/Resources/restart-NetInfo is used to restart netinfo, so maybe adding it there would work? Unfortunately, this file may be overwritten on updates...

There must be more going on against the args given to main; the following public class jtest { public static void main( String args[] ) { System.out.println( "args[ 0 ] is " + args[ 0 ] ); System.exit(0); } } when run $ java jtest...

If you like to see files like this just laying around, check out what's in /usr/share/misc

This is a known problem and has been solved

Ah, a confused daemon; hate when those infest a system...

Does this include root? Also, is there anything logged to /var/log/system.log besides Jan 15 21:01:49 myhost sshd[8870]: Failed password for username from 192.168.7.8 port 33794 ssh2