1) You don't, at least, not exactly.
This is because its functions boil down to being the same thing as the commands available to actual command blocks. Command blocks, if they want to "store" something long-term, use
the scoreboard to do it. They can, for example, ask the scoreboard to look out for a certain event, and have it perform an action when that happens - for example, they could set it up so that every time a player is detected killing a zombie, that player gets a cookie. Or when a player hits a block, a firework fires, and so on - you define an objective, then an action to perform when the objective is met. At least, that's to my limited understanding - and of course, they can assign points! The command block(s) used to configure the scoreboard never get notified of these events, though.
Scoreboard aside, you can also target specific players by testing for them within your command. Let's say you were using a regular command block and you wanted to teleport a player from a specific location, say, 246 65 180, to somewhere else, say twenty blocks above where you grabbed them from. You'd do this:
tp @a[x=246,y=65,z=180,r=1] ~ ~20 ~
Let's say the location to search happened to be on top of your command block. Putting a pressure plate directly above the block and stomping on it would run the command, performing a test for all players at that location and 'porting them up into the air.
Now let's say you wanted to do the same thing with a command computer - first off, it's a little simpler in that it can work out its
own location, so you don't need to put the numbers in manually. The code would look like this:
local x, y, z = commands.getBlockPosition()
while true do
os.pullEvent("redstone")
if rs.getInput("top") then
commands.tp("@a[x="..x..",y="..(y+1)..",z="..z..",r=1] ~ ~20 ~")
end
end
Only now you should be able to see that it becomes trivial to change the behaviour to wait for things other than redstone signals - for example, you could have the loop sleep for a few seconds instead, removing the need for the pressure plate. With an actual command block, such a "timer" would involve setting up an actual redstone timer (or using the scoreboard).
It's somewhat interesting to note that while you can't directly get a command to tell you where a player is, running a teleport command on a player will give you their name and
new location (eg, try storing commands.tp's output into a variable).
2) The only way to turn a system on remotely is via a peripheral call, and command computers unfortunately have no special powers in this regard.
If it helps, remember that command computers can do anything a regular computer can, anything a command block can do,
and they also have commands.getBlockPosition() and commands.getBlockInfo(). Those two extra functions are their only "unique" features, though turtles have a less powerful version of the latter (turtle.inspect()). Put all their abilities together, and they make it possible to turn what would otherwise be a huge cluster of command blocks and redstone circuits, into one Lua script.
