I have a 10.4.11 system here (upgraded from 10.3.9, so it may not be identical to a “fresh” or an "archive and install"ed 10.4.11). Based on my reading of the periodic and periodic.conf manpages and the scripts and configuration files involved (/usr/sbin/periodic itself is a shell script, /etc/periodic// are the daily/weekly/monthly scripts, and /etc/defaults/periodic.conf is a config file), it seems that no output is what you should expect for a successful run of your command. If you want it, all the actual output is appended to these log files: /var/log/daily.log, /var/log/weekly.log, and /var/log/monthly.log.
It should be safe to run these as often as you like, but I have personally never felt the need to force the execution of these periodic jobs. By default, launchd is configured to run these every once in a while. The manpage (launchd.plist) even says it will run them later if the computer is off or asleep during the normally scheduled run time (though this does not seem to be completely reliable on my system). If you run them too often you will abbreviate your “log horizon” because it will rotate the files each time but only for a limited number of rotations (7 or 4 depending on which file). So if the monthly job is run daily and has a limit of 4 rotations for the files it rotates, you will end up wtih 4 days worth of logs instead of 4 months.
The “Repair Permissions” message about SC Info is probably unimportant and unrelated to periodic usage. I have read that the /Uesrs/Shared/SC Info folder (which is usually hidden from Finder) is used to hold iTunes DRM authorizations (when someone authorizes downloads made under their iTunes account to play on your computer, something is stored in there). My guess is that you do not use iTunes or at least do not use it with iTunes Music Store derived music files. To make this error go away, you could try creating the folder, or locating whatever “receipts” (/Library/Receipts) might mention SC Info (you might try Pacifist if find/xargs/lsbom/less/grep scripting is unfamilar; I did not find any such receipt on my system.). Once you know what is expecting SC Info you could try uninstalling it (be sure the receipt is removed too, or the “Repair Permission” message will persist).
-- Create and hide "/Users/Shared/SC Info"
set |SC Info POSIX path| to "/Users/Shared/SC Info"
do shell script "mkdir " & quoted form of |SC Info POSIX path| & ";chmod 777 " & quoted form of |SC Info POSIX path|
tell application "System Events" to set visible of disk item |SC Info POSIX path| to false
The secure.log message comes up since after the /etc/periodic/weekly/500.weekly has rotated the secure.log file, it recreates it as root:admin with ˜640’ permission (˜640’ (octal) equals ˜rw-r-----‘, which (in terms of root:admin user-owner:group-owner) means root user gets read and write, admin group gets read, everyone else has no permission). On my system /Library/Receipts/BaseSystem.pkg specifies secure.log to be root:admin with ˜600’ permission (equals ˜rw-------', root user gets read and write, everyone else has no permission). In my opinion, this is not a serious problem. The script creates files that the admin group can read, but any user in the admin group is (as far as I can tell) a de jure administrator of the computer. There seems very little harm in letting them read the file when they could just as easily sudo and read it if it was root-only as BaseSystem specifies. You could attempt to fix this problem by hacking the 500.weekly script to leave secure.log with the expected permissions. I could tell you exactly what to do, but I really would not recommend bothering.
Summary: The SC Info message is likely related to your non-use of iTunes DRM and could probably be ˜fixed’ by creating the folder in question. The secure.log message is directly related to running periodic’s weekly job. You could hack the script to prevent the minor slackening in permissions or just ignore it (as a long time Unix admin, but a johnny-come-lately to Mac OS X (10.3 in 2004), I wholeheartedly agree with John Gruber’s take on “Repair Permissions”: Seriously, ˜Repair Permissions’ Is Voodoo).