Bug report on tester for #FY4: incorrect logic passed the test

Platform Bug Reports
1

After I done #BV8, I passed #FY4 automatically even though my logic isn’t correct for #FY4.

Based on the instruction on #FY4, my implementation is wrong but the test doesn’t handle it.

Here is the instruction:

For example, if you have jobs [1] and [3] running, the next job gets [2], not [4]

And here’s a snippet of my code:

if let Some(job) = syscmd::handle_system_command(parser_output) {
    let pid = job.pid;

    let job_number = jobs.len() + 1;
    jobs.insert(job_number, job);

    println!("[{}] {}", job_number, pid);
}

So I just add 1 to the length:

    let job_number = jobs.len() + 1;

My jobs is just a BTreeMap<usize, Job>, nothing special.

struct Job {
    pid: u32,
    command: String,
    status: String,
    exit_code: Option<i32>,
}

Please check here for full code: simsh/src/parser/handle_line.rs at d7a50a8273eb5b23fa6a88e4334b36b621c16d8a · skuong/simsh · GitHub

3

Here’s how my logic went wrong but still passes the test:

$ sleep 100 &
[1] 689635
{1: Job { pid: 689635, command: "sleep 100", status: "Running", exit_code: None }}
$ sleep 5 &
[2] 689646
{1: Job { pid: 689635, command: "sleep 100", status: "Running", exit_code: None }, 2: Job { pid: 689646, command: "sleep 5", status: "Running", exit_code: None }}
$ sleep 50 &
[3] 689662
{1: Job { pid: 689635, command: "sleep 100", status: "Running", exit_code: None }, 2: Job { pid: 689646, command: "sleep 5", status: "Running", exit_code: None }, 3: Job { pid: 689662, command: "sleep 50", status: "Running", exit_code: None }}
[2]+  Done                    sleep 5
$ sleep 10 &
[3] 689678
{1: Job { pid: 689635, command: "sleep 100", status: "Running", exit_code: None }, 3: Job { pid: 689678, command: "sleep 10", status: "Running", exit_code: None }}
$
  • [1] is still there. 689635
  • [2] is not created. Old one that is done is: 689646
  • [3] is created and replaced the old [3]. Old: 689662. New 689678
5

Hey @skuong, thanks for highlighting this issue! We’re investigating it and will share an update once we know more.

Thanks again for providing a detailed explanation, that makes it much easier for us to look into.

6

My pleasure

7

Update: the gap-filling behavior described in the instructions is actually how Zsh behaves, not Bash. We’re fixing the instructions to match Bash’s behavior in this PR.

Thanks again for digging into this and pointing it out! @skuong