Look in your secure file and see if there is a host entry listed in there that is unresolvable. When parsing the secure file, all hosts are resolved as they're read. If the host is unresolvable, this will manifest itself as ~10 second delay (per host) in NSH.
Problem sorted ;) . I have some hosts I can only connect to once I authenticate through a firewall - these were causing the problem, commented them out and its fine now.
So let me get this right, once NSH has initialised it still re-reads the SECURE file whenever I want to execute a command? for example - a simple 'ls' command executed locally causes the same effect when I have those uncontactable hosts in my SECURE file.
Jobs a gooden
That's correct (each command re-reads the SECURE file). The commands that run don't have access to the memory that NSH has. All NSH does (and all shells really) is say "launch this command". That command then launches as a separate entity from the shell.
So NSH doesn't re-read the secure file. It reads it when you first start it and then when you run a command like "ls" it needs to read the secure file as well because it has no real connection to what NSH did other than exported environment variables. Only commands that are directly built into the shell (like cd) should not have to re-read the secure file (as they have access to NSH' memory). Commands that are not built into the shell have to initialize it on their own.
For anyone else searching for solutions to this problem:
I've just had the same problem with a server and it was due to unresolvable hostnames in exports