What is the format of the standard claim script? With reference to this:
https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash

It would seem the claim script is simply the signature consisting of S and R and the public key.

However I know at least the signature gets DER encoded, which is fine I found a library for that, but I don't know the details. For instance is it:
DER(S,R)+pubkey, DER(R,S)+pubkey or DER(S+R+pubkey) and so on, there are many permutations etc.?

I'm looking for something like this where you can see what each byte is supposed to be:
https://en.bitcoin.it/wiki/Protocol_specification
In short the answer is this:

InScript length                               : VarInt (1-9 bytes)
PushData operation of R/S/Hash_all/DER bytes  : OP_PUSH (1-9 bytes)
DER sequence type byte                        : 0x30
DER sequence length                           : 0x44-0x46
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 R bytes, left padded with 0x00 IF leftmost byte &gt;= 0x80 - hence varying lengths above.
DER integer type                              : 0x02
DER integer length                            : 0x20-0x21
32 S bytes, left padded with 0x00 IF leftmost byte &gt;= 0x80 - hence varying lengths above.
Sighash_All type byte                         : 0x01
PushData operation of publickey bytes         : OP_PUSH (1-9 bytes)
PubKey version/type byte                      : 0x04
Public key in 64 bytes of data - X and Y 32 bytes each


Answer taken from here:
https://bitcointalk.org/index.php?topic=653313.0

After looking at it becomes pretty obvious that DER was a mistake on Satoshis part and something provided to him by OpenSSL.

I mean why encode unsigned integers as signed - then pad them to make them unsigned again.

Why these sequence and length definitions when we already know the length from the push byte op - why DER encode at all when its ALWAYS 32 bytes R followed by 32 bytes S?

Clearly its pretty silly.