oktosha/codam-minishell

Minishell project at Codam (School 42)

codam-minishell's Issues

Submit the code to the intranet

The flow will run on merge to main:

• clone repo from intra
• remove everything in the intra repo folder except ".git"
• copy contents of the "kotishell" folder into intra repo
• if changes detected, the work is commited
• commit message is the message of the last commit in the github repo
• commit author is the author of the last commit in the github repo

feat: Exec

Better exec:

proper return codes

• For syntax errors
• For libraries failing kotishell: failed malloc, failing pipes, ...
• For built-ins
• For child processes (normal and built-ins):
  • check WIFEXITED
  • also check errno for execve to get precise error cause
  • also handle death by signal

Add pull-request template

Add action template for tokenize tests

feat: full tokenizer

Fix submit-to-intra for multiline commit messages

feat: Parsing part of lifecycle (pipes and cmds)

Basic lex, expand and parse. We need to make the parsing be able to connect to exec.
Only tokens used: pipes and commands

fix: use mini_free and mini_malloc in kotishell

Inside kotishell we use our own mini_free and mini_malloc.
Inside tests we use the standard free and malloc functions.

fix: Error handling for emojis

fix:
void l_tk_symbol_error(t_tk_so_far *so_far)

fix:
mini_putstr_fd(" \033[0;31m\x1B[1m-> Unsupported symbol\n", 2);

Initial upload Lena

Lena added:
pipex, libft, Makefile, src, include folders

feat: Lifecycle code to glue stuff

feat: Full lexer

The goal of lex is to do enough work to prepare for the env vars expansion.

2.1 Mark quotes as important and non-important
2.2 Mark heredoc, pipe, redirect depending on the quotes
2.3 Mark variables ($WORD and $?) taking heredoc and quotes into account

feat: Parsing words update

Currently parsing splits /usr/bin/ls into separate words bases on the slash symbol.
Also, a dot is considered as an other symbol

fix: expand whitespaces

Fix the merging of whitespaces to commands. Commands and their arguments should be stored in separate nodes.

fix: Close extra pipes in children

Valgrind behaves weirdly probably due to unclosed pipes. Every forked child receives all the pipes of the parent via fork but interacts only with the 2 file descriptors passed to l_ex_fork. A good child must close all the pipes it doesn't use.

Originally posted by @Oktosha in #30 (comment)

Add a cat in Makefile

      \    /\ 
       )  ( ')      - Meow
      (  /  )
       \(__)|

fix: lifecycle kotivar state

Add proper envp split into kotivar

Update norm action

feat: basic exec

Write a basic way to launch non-built-in commands:

• come up with a data structure passed from the parsing part into exec part
• do basic launching
• write a basic testing script (at least for manual testing)

This issue isn't about integrating signals or handling all the weird cases

feat: Better test and debug

We need:

1. Scripts that launch our tests
   a. Scripts for each test group (tests for one module)
   b. Script that launches all the tests and predicts if the github action workflows will fail (essential to iterate faster when fixing failing checks)
   c. Maybe scripts for individual tests, especially if they require passing extra flags to valgrind (like --track-fds=yes that is essential for debugging files and pipes but useless and annoying for parse steps)
   d. Maybe an alias for valgrind with reasonable flags, to type val ./ex_tests instead of valgrind -s --leak-check=full ./ex_tests (and I want to add this alias as a part of devcontainer settings so it works out of the box in all our newly created codespaces but stop me pls)
2. Better debug printing
   a. Let's create proper dbg module
   b. Functions that can print all our data types (tokens, commands, auxiliary things)
   c. Finctions that print formatted debug messages to stderr or file (file output should be useful for debugging child processes behaviour) and can be switched off in production kotishell on the compilation stage
3. Better ways to write tests
   a. An easy way to create objects of our data types (tokens, commands, auxiliary things)
   b. An easy way to compare and check our objects
   c. Better code organisation for tests (let's put all printing, creating and comparing into the dbg module and split tests into more independent debuggable executables)

I think that we should invest in better debug asap because it will speed us up. Debugging pointers in VSCode the way we tried it is a pain.

feat: exec structs

We defined the structs that will be needed by the exec part from the parsing part.

Add license - unlicense

Re: Daria
Link: https://unlicense.org/

feat: Basic tokenizer

Split string by whitespace (into words)

fix: Better token types and lists