Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to identify the current sketch and its location #1

Open
tigoe opened this issue Aug 23, 2018 · 8 comments
Open

Add a way to identify the current sketch and its location #1

tigoe opened this issue Aug 23, 2018 · 8 comments
Labels
type: enhancement Proposed improvement

Comments

@tigoe
Copy link
Member

tigoe commented Aug 23, 2018

board attach works OK, but users who are moving between a few tasks may forget which sketch they're on. Making arduino-cli sketch return the name and path of the current sketch would be handy.

@cmaglie cmaglie added the type: enhancement Proposed improvement label Aug 30, 2018
@cmaglie
Copy link
Member

cmaglie commented Sep 20, 2018

@tigoe may you expand a bit more on that?
I can see that the shell prompt already gives you the working directory that reveal also the sketch name, for example in a typical session I have:

cmaglie@crocchetta:~$ cd Arduino
cmaglie@crocchetta:~/Arduino$ ls
blink  libraries  xxxx  yyyyy
cmaglie@crocchetta:~/Arduino$ cd blink/
cmaglie@crocchetta:~/Arduino/blink$ 
cmaglie@crocchetta:~/Arduino/blink$ 

at this point is clear that I'm working on the blink sketch because the shell prompt just tell me the directory I'm currently in, so having another command like:

cmaglie@crocchetta:~/Arduino/blink$ arduino-cli sketch
Sketch: blink
Directory: /home/cmaglie/Arduino/blink

looks like a bit redundant.

@tigoe
Copy link
Member Author

tigoe commented Sep 20, 2018

You're assuming that I've cd'ed to the project directory before I start working. That's not always the case. Sometimes I might be working on a group of sketches all at once, kept in different directories.

@cmaglie
Copy link
Member

cmaglie commented Sep 21, 2018

If you're working on multiple sketches you have to tell the CLI which one you're referring to.
The only case of "implicit" sketch (when you omit it) is the one in the current working directory.

Or maybe I'm totally misunderstanding your use case, if you can provide a transcript of a terminal session to show me it may be quicker a way :-)

@tigoe
Copy link
Member Author

tigoe commented Sep 21, 2018

I can't, because the transcript is not on my own machine :(. But I was working on a machine yesterday where the primary interface is a screen reader, not visual reading, and so therefore the owner of the machine customized the bash prompt so that, instead of giving the directory and therefore reading the whole long prompt every time, it just gives $. Try turning on the VoiceOver screen reader on MacOS and operating your computer that way, and you'll get a sense of it. command-F5 will turn it on.

Then, the person preferred to work out of the home directory, therefore requiring /Documents/Arduino/sketchName every time. tab helps, but it's still a pain in the butt. Likewise, arduino:avr:uno every time you want to upload is difficult. If there is a profile for the sketch, so that there's a default sketch directory for it, and a default board type, and port, then you can just type

$arduino-cli upload

for repeated uploads instead of
cmaglie@crocchetta:~/Arduino/blink$ arduino-cli upload -p /dev/cu.usbmodem14111 -b arduino:samd:mkrzero ~/Documents/Arduino/cliTest/

Through the screen reader, my line reads in a second or two. Yours takes about 15 seconds, slowing development time considerably.

Of course, I might forget what my default is, so being able to ask for it, maybe by:

$arduino-cli board id

or

$arduino-cli sketch location

would help a lot.

This is difficult to convey without a screen reader, but I am happy to get on hangouts with you and give you the full experience, Cristian.

@cmaglie
Copy link
Member

cmaglie commented Sep 21, 2018

customized the bash prompt so that, instead of giving the directory and therefore reading the whole long prompt every time, it just gives $

ok this is the detail that I was missing. So my transcript above, in your case, will look like:

$ cd Arduino
$ ls
blink  libraries  xxxx  yyyyy
$ cd blink/
$ 
$ 
[...and with the proposed sketch command...]
$ arduino-cli sketch
Sketch: blink
Directory: /home/cmaglie/Arduino/blink

and now your request makes perfect sense.
BTW the nice think with the shell is that is highly customizable, so you can get the same information right now:

$ pwd
/home/cmaglie/Arduino/blink

(pwd means "print working directory") or if you are interested in just the name of the sketch you can do something like:

$ basename /home/cmaglie/Arduino/blink
blink
$ basename $(pwd)
blink
$ alias sk="basename $(pwd)"
$ sk
blink

basename returns just the last part of the path, so you can program a shell alias called sk as in the example above, this will make your experience even more quicker than typing arduino-cli sketch.

@tigoe
Copy link
Member Author

tigoe commented Sep 21, 2018

I know how pwd works....

The issue here isn't knowing where I am, it's knowing where my sketch is, when I am not in the same directory. And doing so in a not-overly-verbose way. The two are not necessarily the same, You're assuming only one way of working with the cli, but bash supports coming at it from many directions.

@cmaglie
Copy link
Member

cmaglie commented Sep 21, 2018

Ok, then I'm happy to do an hangout to see your workflow, drop me a line via email to coordinate.

@tigoe
Copy link
Member Author

tigoe commented Sep 21, 2018 via email

per1234 pushed a commit that referenced this issue Nov 16, 2020
Fixed memory leak in CborArray, fixed ssize_t, #define CBOR_INT_T int
per1234 pushed a commit that referenced this issue Nov 16, 2020
per1234 pushed a commit that referenced this issue Nov 16, 2020
@per1234 per1234 reopened this Mar 30, 2021
per1234 added a commit that referenced this issue Aug 9, 2021
Create tool for linting Arduino projects
cmaglie added a commit that referenced this issue May 22, 2024
* Enabled more checks in golangci-lint

* Removed unreachable code (impossible condition detected by linter)

internal/arduino/sketch/sketch.go:108:14: nilness: impossible condition: non-nil == nil (govet)
        if mainFile == nil {
                    ^

* Removed function alias for i18n.Tr

This allows a deeper lint-check of printf style functions, like:

  commands/instances.go:344:46: printf: github.com/arduino/arduino-cli/internal/i18n.Tr format %v reads arg #1, but call has 0 args (govet)
		s := status.Newf(codes.FailedPrecondition, i18n.Tr("Loading index file: %v"), err)

* Fixed a lot of i18n.Tr formatting errors

This commit fixes invalid calls to i18n.Tr.

1. Missing positional arguments, for example:

  return fmt.Errorf(i18n.Tr("installing %[1]s tool: %[2]s"), tool, err)

in the above case the positional arguments must be part of the Tr call:

-    return fmt.Errorf(i18n.Tr("installing %[1]s tool: %[2]s"), tool, err)
+    return fmt.Errorf(i18n.Tr("installing %[1]s tool: %[2]s", tool, err))

2. This also makes the fmt.Errorf call useless and it could be replaced by
the less expensive errors.New:

-    return fmt.Errorf(i18n.Tr("installing %[1]s tool: %[2]s", tool, err))
+    return errors.New(i18n.Tr("installing %[1]s tool: %[2]s", tool, err))

but we have cases of useless calls even when the string is a constant,
for example:

-    err := fmt.Errorf(i18n.Tr("no instance specified"))
+    err := errors.New(i18n.Tr("no instance specified"))

Unfortunately, this imperfection is not detected by the linter.

3. The "%w" directive is not supported directly in i18n.Tr, so we have
   to wrap it around another fmt.Errorf:

-    return nil, fmt.Errorf(i18n.Tr("reading library headers: %w"), err)
+    return nil, fmt.Errorf("%s: %w", i18n.Tr("reading library headers"), err)

* Removed useless call to i18n.Tr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

5 participants