This depends on the target platform, compiler and compile flags.

For example, GCC 7.2 x86 in debug mode (-O0) aligns stack frames on a 16-byte boundary and allocates a frame pointer (ebp).

Example: (godbolt link)

bof(char*):
        push    ebp                   ; -4
        mov     ebp, esp           
        sub     esp, 40               ; -40
        sub     esp, 8                ; -8
        push    DWORD PTR [ebp+8]     ; -4
        lea     eax, [ebp-32]         ; 32 bytes to top of stack frame
        push    eax                   ; -4
        call    strcpy                ; stack is aligned to 16 bytes (-64)
        add     esp, 16
        mov     eax, 1
        leave
        ret

With optimization on (-O2) the frame pointer is omitted but the stack is still aligned on 16 bytes (godbolt link):

bof(char*):
        sub     esp, 52               ; -52
        push    DWORD PTR [esp+56]    ; -4
        lea     eax, [esp+20]         ; 36 bytes to top of stack frame
        push    eax                   ; -4
        call    strcpy                ; stack is aligned to 16 bytes (-64)
        mov     eax, 1
        add     esp, 60
        ret

With a forced 4-byte stack alignment (-O2 -mpreferred-stack-boundary=2) (godbolt link):

bof(char*):
        sub     esp, 24               ; -24
        push    DWORD PTR [esp+28]    ; -4
        lea     eax, [esp+4]          ; 24 bytes to top of stack frame
        push    eax                   ; -4
        call    strcpy
        mov     eax, 1
        add     esp, 32
        ret

With stack protector on (-O2 -fstack-protector-all) (godbolt link):

bof(char*):
        sub     esp, 52                      ; -52
        mov     eax, DWORD PTR gs:20
        mov     DWORD PTR [esp+36], eax      ; stack check value at -16 (-52+36)
        xor     eax, eax
        push    DWORD PTR [esp+56]           ; -4
        lea     eax, [esp+16]                ; 40 bytes to top of stack frame, leaving exactly 24 bytes to check value
        push    eax
        call    strcpy
        add     esp, 16
        mov     edx, DWORD PTR [esp+28]
        xor     edx, DWORD PTR gs:20
        jne     .L5
        mov     eax, 1
        add     esp, 44
        ret
.L5:
        call    __stack_chk_fail

Other compilers might have entirely different results.

In real life, a buffer overflow is exploited in assembly mode by analyzing instructions and counting the bytes to the function's return address, so it doesn't matter what the source code was or how it was compiled (this info is often unavailable anyway).

I figured out what the problem was. I had to link the zsh to /bin/bash/. I skipped that because I thought I only had to do that if I was using Fedora. I was using Ubuntu.